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Kedvenc operációs rendsze- 
rünk töretlenül fejlődik, is- 
mertsége és használata egy- 
re jobban teret nyer az ott- 
honi felhasználók számí- 
tógépein. A Sulinet Expressz 
berkein belül Linuxszal 
értékesített számítógépek is 
hozzájárultak ehhez, azon- 
ban sokukra az a csúfos vég 
várt, hogy hazaszállítás után 
azonnal az a bizonyos másik 
rendszer kerül fel rájuk, a 
pingvinnek esélyt sem adva 
a bemutatkozásra. 

A magyar nyelven megszólaló két 
Linuxon kívül egy újabb versenyző 
érkezett, ez a Mandrake alapokon 
nyugvó blackPanther-Linux. Egyelőre 
még csak Live-CD formában érhető el, 
fejlesztői azonban tervezik a telepítő- 
készlet kiadását is. A Linux és a hozzá 
tartozó programok fejlesztési üteme 
nagyobb, mint valaha volt, a 2.6-os 
sorozatú rendszermag lassanként 
kinövi gyermekbetegségeit, és nyu- 
godt szívvel használhatjuk majd min- 
dennapos munkánk során. Biztosan 
van, aki emlékszik a 2.4-es megjele- 
nését követő bizonytalankodásra: 

a használjuk vagy ne használjuk témá- 
ban, volt aki kezdetektől átállt rá, de 
akadt olyan is, aki csak a 10-es változat 
után érezte biztonságban adatait. 
Mindenesetre egy biztos a Linux 
immáron kamaszodik! 
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Programvadászat 


Debian másképpen 

Sokan azt gondolják, hogy a Debian 
GNU/Linux csak az elvetemült linu- 
xosoknak való, ennek cáfolatául mosta- 
ni CD-mellékletükre feltettük a Knoppix 
V3.4 Linux-kiadást, ami egy CD-ről in- 
dítható , LÍVE" Debian rendszer. A kí- 
váncsiskodók is kipróbálhatják, nem 
szükséges telepíteni a merevlemezre, 
ha azonban valaki a kipróbálás közben 
mégis úgy döntene, hogy szeretné fel- 
pakolni, annak sincs semmi akadálya. 
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Rendszerigény 

A rendszer KESO s 

mum 128 MB memória szükséges. Ha 
valaki nem rendelkezik SWAP lemez- 
résszel, akkor a 256 MB memória a leg- 
kevesebb, ekkora szükséges ahhoz, 
hogy maga a rendszer és az alkalma- 
zások is elférjenek a fizikai memóriá- 
ban, mivel csodák nincsenek, több me- 
móriaigényes program egy idejű futta- 
tásához még több memória szükséges. 


A rendszer indítása 

Rendszerünket állítsuk be olyan mó- 
don, hogy a korongról induljon. Ha si- 
keres a rendszerindítás, akkor egy sok- 
féleképpen paraméterezhető indítási 
menüben találjuk magunkat. A kapcso- 
lókat az F2 és F3 billentyűvel érhetjük 
el. Akad belőlük bőven, és a neveik 
magukért beszélnek. Nekem a 2.6-os 
rendszermaggal az SCSI felismerése so- 
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rán meggyűlt a bajom, ezért a noscsi 
kapcsolóval kellett indítanom. Akik 
esetleg kíváncsiak a linuxos ablakkeze- 
lők sokféleségére, azok szintén ebben 

a menüben adhatják meg, melyik in- 
duljon el. Ezt a desktop-valami (mely- 
ben a valami az ablakkezelő neve) pa- 
ranccsal érhetjük el. 
Alapértelmezettként egyébként a KDE 
3.4-es grafikus környezet indul el, ez 
eléggé memóriaigényes, amit a várako- 
zási idő hosszúságán is lemérhetünk. 
Alkalmazásokkal bőven el vagyunk 
látva, található benne minden mi szem 
szájnak ingere: szövegszerkesztő, bön- 
gésző, levelező, csevegő, grafikai és 
még sorolhatnám miféle programok. 


Beállítás 

Az ablakkezelők menüjéből érhető el 
egy Knoppix almenü, ebben nagyon 
sok hasznos beállítóprogram található, 
ezek a kezdő felhasználók életét igen- 
csak megkönnyíthetik. Például ilyen 
alkalmazás a hálózati beállítóprogram 
(netcardconfig), mellyel gyerekjáték 
a hálózati kártyánk beállítása. Esetleg 
van GPRS kapcsolatunk is? Erre is 
akad megoldás, a GPRS connection. 


Telepítés 

A knx2hd parancs kiadása után, pár 
kérdésre választ kell adnunk a rend- 
szerünket illetően, majd egy viszony- 
lag hosszadalmas fájlmásolás kezdő- 
dik, ennek befejezésekor Knoppix 
rendszerünk a merevlemezről in- 
dítható lesz. 





Telepítés után 

A Knoppix teljes mértékben Debian 
kompatibilis, ennek köszönhetően az 
apt forrásban fellelhető összes prog- 
ram rendelkezésre áll, ami valljuk meg 
nem kevés. (Jelenleg több mint 10 000 
csomagról van szó). Ennek köszönhe- 
tően az eddig Debiant használók egy 
Knoppix rendszert is ugyanolyan mó- 
don tudnak karbantartani. Az apt-get 
kiválóan működik, így ha valamilyen 
programot nem találunk meg, de mi 
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mégis szeretnénk használni, akkor 

az apt-get update után az apt-get 
install] csomagnév segítségével tele- 
píthetjük. A Knoppix kínál erre egy 
felhasználóbarátabb módszert is, ez 
pedig a KPackage. 

Mindent összevetve, mindenkinek 
ajánlom a Knoppix rendszer kipróbá- 
lását. Sajnos nem beszél magyarul, ezt 
a kellemetlenséget megszüntethetjük, 
ha telepítés után ki adjuk az apt-get 
install kde-i18n-hu parancsot, ez- 
után beállíthatjuk a KDE-t, hogy ékes 
anyanyelvünkön szólítson meg ben- 
nünket. 

Jó szórakozást! 


Csontos Gyula 

(Csontos. Gyulaolinuxvilag.hu) 
A Linuxvilág szakmai és 
CD-szerkesztője. Szabadide- 
jében szívesen mászik 
hegyet és kerékpározik. 





Ujabb VAIO-csalátdtag 

A Sony Japan VAIO Pocket néven 
újabb Apple iPod-versenytársat jelen- 
tett be. A készülékbe 20 GB-os merev- 
lemez és 20 órás üzemidőt biztosító 





akkumulátor kerül, kijelzője 320 x256 
képpont megjelenítésére képes, továb- 
bá rendelkezik egy Memory Stick Duo 
aljzattal is. A VAIO Pockethez -— nem 
meglepetés - a Sonytól Connet néven 
internetes Zzenevásárlási lehetőséget 
kínáló szolgáltatás is társul. A Sony 
ugyan kicsit lassan válaszolt az Apple- 
féle ilunes sikerére, ám a mögötte álló 
Sony Music kiadóval minden esélye 
megvan a sikerre. 

2 http:/www.vaio.sony.co.jp 


frissülő Opie 

Az Open FPFalmtop Integrated 
Environment (Opie) tervezet vezetői 
megjelentették csomagjuk legújabb, 
1.1.3 számot 
viselő elő- 
zetes válto- 
zatát. A kö- 
vetkező 
üzembiztos 
változat az 
1.2-es lesz, 

a mostani 
kiadással elsősorban a fejlesztők figyel- 
mét és rokonszenvét szeretnék elnyer- 
ni. Az Opie - kézigépekre, webtáb- 
lákra stb. szánt grafikus környezet — 
utolsó üzembiztos változata tavaly au- 
gusztusban vált elérhetővé, a mostani 
kiadás ehhez képest komoly fejleszté- 
seket ígér, miközben az 1.0.x ág fej- 
lesztését abbahagyják. A csomagba új, 
SOLite alapú személyi adatkezelő 
adatbázismotor, e-könyvolvasó és kép- 
nézegető kerül, továbbfejlesztették 

a kézírás-felismerő modult, és renge- 
teg egyéb részét is átszervezték, le- 
tisztították. 

2 http:/opie.handhelds.org 





www.linuxvilag.hu 





Gyorsuló Chello 

2004. május 1-jétől hivatalosan is gyor- 
sabb internetelérést kapnak a Chello- 
előfizetők. A korábban egyszerűen 
Chello néven futó csomagot ettől kezd- 
ve Chello Classicnak nevezik, sebessé- 
ge az eddigi 
512 kbss le- 
töltés, illetve 
128 kb/s fel- 
töltés helyett 768 kbvs letöltés, illetve 
256 kbss feltöltés. Aki nem elégszik 
meg a Classic díjcsomag 15 GB-os 
adatforgalmi határával, az igényelhet 
20 GB-os adatforgalmat és 1024 kb/s 
letöltési, illetve 512 kb/s feltöltési se- 
bességet kínáló Chello Plus csomagot 
is. Az átállás részeként a UPC már hó- 
napok óta folytatja kábelmodemjeinek 
korszerűbb készülékekre való lecseré- 
lését. A változás díjemeléssel nem jár, 
így a Chello Classic a maga havi 12 
ezer forintos költségével és megnövelt 
sebességével a többi internetszolgál- 
tatáshoz képest továbbra is több mint 
versenyképesnek mondható. 

2 http:/www.chello.hu 


Csak nagyban érdemes 

Az Optware nemrég bemutatott optikai 
meghajtója új is, nem is, az viszont biz- 
tos, hogy sokaknak tetszene, ha hama- 
rosan megvásárolhatnák a 200-300 GB- 
os kapacitást ígérő készüléket. 

A meghajtó holografikus elven műkö- 
dik, ami nem újdonság. A jelenlegi ho- 
lografikus tárolók két lézersugarat, egy 
referencia- és egy jelsugarat használ- 
nak. Ezeket két lencsén vezetik keresz- 
tül, és ez okozza a legtöbb fejtörést, 
ugyanis a hibátlan adatátvitelhez rend- 
kívül pontosan kell pozícionálni nem- 
csak a lencséket, de az adathordozót is. 
Az Optware e nehézség leküzdésére 
dolgozott ki egy egyszerűbb, egyetlen 
lencsével működő megoldást. Várako- 
zásaik szerint az erre épülő meghajtók 
és a hozzájuk szükséges 12 cm-es leme- 
zek -— noha végleges terméket még 

a bemutatókra sem tudnak vinni — 
már jövő nyáron kaphatók lesznek. 

A DVD utódjának szánt formátumokat 
támogató nemzetközi cégeknek azon- 
ban bizonyára rosszul jönne egy ilyen 
újdonság, ezért ha az Optware véletle- 
nül eltűnne a süllyesztőben, akkor 
legfeljebb változatos összeesküvés- 
elméletek kidolgozásával vigasztalód- 
hatunk. 

2 http:/www.optware.co.jp 
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Az ötödik POWER 

Az IBM bemutatta első POWER5 
processzorra épülő kiszolgálóit. Az 
eServer sorozat legújabb, i5 jelölésű 
tagjai 1-4 utas gépek, operációs rend- 
szerük az OS/400 leg- 
újabb kiadása, az 
15/OS, valamint AIX 
DL, Linux és Win- 
dows lehet. A gépek 
erőforrásait ebben 

a kategóriában meg- 
szokott módon logi- 
kai tartományokra le- 
het osztani, így egy- 
szerre több operációs 
rendszer futtatására 
is használhatók — mi- 
nő szentségtörés, 
megfelelő összeállí- 
tásban egyetlen do- 
boz, közös memóriával és lemez- 
hellyel futtatja a vállalat Unix, Win- 
dows és Linux alapú kiszolgálóprog- 
ramjait. A kiszolgálókhoz nemcsak az 
operációs rendszer jár, de az ÍBM DB2 
UDB adatbázisa és az e-kereskedelmi 
alkalmazásokhoz használható Web- 
Sphere Express-motor is. 

A POWER5 processzorok 64 bitesek, 
tranzisztoraik száma 276 millió. A lap- 
kák 0,13 mikronos SOI eljárással és 
rézvezetékekkel készülnek. Képesek 
az egy idejű többszálas programfutta- 
tásra, és mivel minden processzorban 
két processzormag található, az operá- 
ciós rendszer számára gyakorlatilag 
négy program egyidejű futtatásra 
képes egységként látszanak. 

Az IBM állítása szerint az új 15 gépek 
elődeikhez képes negyven százalékkal 
jobb ár/teljesítmény-mutatóval rendel- 
keznek. Ennek ellenére nem fog ilyes- 
fajta erőmű kerülni minden asztalra, 
ugyanis listaár szerint még a kisvállal- 
kozásoknak szánt alapváltozatot sem 
adják kétmillió forint alatt. 

2 http:/www.ibm.com/eserver 


Párosan lesz szép az élet 

Az Intel megszakította lejas és 
Jayhawk kódnevű processzorainak 
fejlesztését. A lejas a jelenleg futó 
Pentium 4 Prescott processzorok 
utóda lett volna, míg a Jayvhawkot 
a kiszolgálók piacára szánták. Mind- 
két lapka egymagos lett volna, he- 
lyettük azonban kétmagos pro- 
cesszorok megjelentetése mellett 
döntött az Intel. 
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lermészetesen ahány nézőpont, 
annyi indok az Intel döntése kap- 
csán. Akadnak, akik úgy vélik, a me- 
gahertzek számának növelése, a csík- 
szélesség csökkentése a továbbiakban 
nem vezet célra. Mások - az előbbi 
indokot nem kizárva — úgy vélik, 

a processzorainak órajelét és a futó- 
szalagok hosszát hosszú évek óta 
folyamatosan emelő Intel elért egy 
olyan szakaszba, amikor termékeinek 
teljesítményét már nem tudja ezekkel 
a módszerekkel emelni - erre utal 
egyébként az is, hogy a cég nemrég 
újfajta modellszámozást vezetett be. 
A hivatalos indoklás természetesen 
ennél sokkal inkább marketingszagú: 
a többszálas programok, a több alkal- 
mazás egyidejű futtatását igénylő 
környezetek az irodákból egyre in- 
kább eljutnak az otthonokba is, így 
inkább a kétmagos felépítésű pro- 
cesszorok tudnak megfelelő teljesít- 
ményt nyújtani a felhasználók szá- 
mára. A bejelentéstől függetlenül az 
Intel a jelenleg futó Prescott pro- 
cesszorokat sem adja fel, órajelüket, 
az eredeti terveket követve, egészen 
4 GHZz-ig kívánják növelni. 

2 http:/wwwiintel.com 


Csak a név tűnik el 

Május elsejével kezdődött az a fo- 
lyamat, melynek eredményeként 

a Westel márkanév — majdnem egy 


. . T-Mobile: 


évtized után - lassan ki fog kopni 

a hazai köztudatból. Az új név, a 
1-Mobile több nyugati országban is 
ismert, bevezetésének előnye az ígére- 
tek szerint nemcsak abból áll majd, 
hogy a Magyarországra látogató kül- 
földiek jobban eladható névvel talál- 
koznak, hanem abból is, hogy a kül- 
földre látogató magyarok olcsóbb, 
előnyösebb szolgáltatásokat kapnak 
utazásaik során. A névváltás természe- 
tesen nem egy csapásra zajlik, hiszen 
rengeteg hirdetés lecseréléséről, üzle- 
tek arculatának átalakításáról kell gon- 
doskodni. A váltás során új nevet kap- 
tak a díjcsomagok, új megjelenésű 
Domino kártyákat adtak ki, ám ettől 
függetlenül a tarifák és az elérhető 
szolgáltatások köre -— egyelőre — nem 
változott. 

2 http:/www.t-mobile.hu 


siemens NetCheck 

A Siemens nemrég jelentette be Net- 
Check nevű új termékének beveze- 
tését, amit IP-hálózatok minőségvizs- 
gálatára fejlesztettek. 

A NetCheck szolgáltatás minőségi 
(005) méréseket végez az IP-hálóza- 
tokon. Ennek nyomán eldönthető, 
hogy a hálózat alkalmas-e például 
VolP átvitelre, adatbázisok működte- 
tésére, irodai helyi hálózati (LAN) 
alkalmazásra, illetve egyedi igényeik 
kielégítésére. Elemzi a hálózat műkö- 
dését a OoS jellemzők időbeni elosz- 
lása szerint, valamint az elemzés 
eredménye alapján minőségi hibák 
észlelése esetén riasztásokat hoz létre. 
A Siemens NetCheck megoldja a há- 
lózat folyamatos figyelését is, és hiba 
esetén azonnal riasztást küld. A rend- 
szer három forrás alapján riaszt: ren- 
delkezésre állási, minőségi (guality) 
vagy SLA okból. 

A riasztásokat megjeleníti a képernyőn, 
vagy igény szerint elektronikus levelet, 
vagy SMS-t küld. 

Az előzetes számítások szerint a meg- 
oldás- és szolgáltatáscsomag révén 

a hálózat leállásából, az adatok sérü- 
léséből, a partnerek nem megfelelő 
szinten történő kiszolgálásából szár- 
mazó veszteségek elkerülésével 

a hálózatfelügyeleti költségek akár 
tízszerese is megtérülhet. 

A megoldás szabadon alakítható, 
illetve illeszthető a vállalati rendsze- 
rekhez, bármikor fejleszthető, vala- 
mint több szintű szolgáltatást nyújt 

a felhasználók számára, így a hálóza- 
ti hibák, vírustámadások időben fel- 
ismerhetők. 

2 http:/www.siemens.hu/icn/netcheck 


91n 

A Sun Microsystems az x86 alapú 
rendszerei iránti növekvő keresletre 
válaszul a továbbiakban éves díjfizeté- 
sű csomagokban is kínálja Solaris ope- 
rációs rendszerét. A vásárlók 100, 500 
és 2000 darabos csomagokat rendel- 
hetnek, a díj megfizetése a kapcsolódó 
szolgáltatások és a támogatás igénybe- 
vételére is feljogosít. 

A Sun árait tekintve igyekezett vetély- 
társai alá menni, így a Solaris 1-4 utas 
gépekre a Windows Server 2003 és 

a Red Hat Enterprise Linux operációs 
rendszernél jóval olcsóbban szerez- 
hető meg. 

2 http:/www.sun.com 


N-Gage átpofozva 

A Nokia bemutatta N-Gage játékgép- 
telefonjának megújított változatát. Az 
eredeti N-Gage, mely egyébként to- 
vábbra is kereskedelmi forgalomban 
marad, meglehetősen sok bírálatot ka- 





pott mind a játékosoktól, mind az ipar- 
ág többi szereplőjétől. A Nokia most 

a sok panaszt kiváltó, mondjuk úgy, 
tervezési félreértéseket próbálta meg 
kiküszöbölni. Az N-Gage OD először is 
olcsóbb lesz elődjénél, a Nokia állítása 
szerint az FM rádió és az MP3-lejátszó 
kihagyása miatt. Másrészt minden fon- 
tosabb jellemzőjén javítottak, az új ké- 
szülék kisebb elődjénél, kívülről, az ak- 
kumulátor levétele nélkül is hozzáfér- 
hető MMC-tfoglalatot, könnyebben ke- 
zelhető billentyűzetet, nagyobb fény- 
erejű és több szín megjelenítésére ké- 
pes kijelzőt és erősebb akkumulátort 
kapott. Elmarad róla az USB-kapu, 
adatkapcsolatok létesítésére a telefon 
Bluetooth-csatolója használható. 

Az N-Gage készülékekre egyelőre vi- 
szonylag kevés játék kapható, a Nokia 
tervei szerint ez a szám év végére 
jelentősen növekedni fog. 

2 http:/www.n-gage.com 


Egyre vonzóbb Evolution 

A Novell két fontos bejelentést is 

tett: egyrészt hamarosan elkészül 

az Evolution 2.0, másrészt a hozzá 

írt Connector 

for Microsoft 
Exchange Server 
(amelyből a jelen- 
legi változat az 
1.4-es) a további- 
akban nyílt forrás- 
sal is elérhető. 

A csatlakozó segítségével a jelenleg 
Exchange Server 2000/2003 alapú 
rendszerhez kapcsolódó felhasználók 
könnyedén, adataik elvesztése nélkül 
térhetnek át az Evolution használatá- 
ra. Nem kevésbé lényeges az sem, 
hogy a linuxos munkaállomások tele- 
pítése mellett döntő cégek munkatár- 
sai továbbra is kapcsolatban marad- 
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hatnak windowsos gépeken dolgozó 
kollégáikkal, illetve mindkét tábor 
azonos háttérrendszerekhez csatlakoz- 
hat, ami megkönnyíti a fokozatos 
vagy részleges átállásokat. 

A várhatóan a harmadik negyedévben 
megjelenő Evolution 2.0 több újdonsá- 
got is tartogat. Iovábbfejlesztett 
együttműködési lehetőségeket fog kí- 
nálni, beépített levélszemétszűrőt kap, 
S/MIME és PGP alapú tanúsítványke- 
zelés kerül bele, adatokat lesz képes 
összehangolni Palm és PocketPC esz- 
közökkel, továbbá szorosan egybeépül 
a linuxos munkaasztalokkal és a Gaim 
azonnali üzenetküldő programmal. 
Az Evolutionre még várni kell, ellen- 
ben a csatlakozó máris szabadon le- 
tölthető a Novell honlapjáról. 

2 http:/www.novell.com 


Tárolóhálózat olcsón 

A Coraid EtherDrive eszközével újsze- 
rű, a korábbinál lényegesen olcsóbb 
módon építhetünk tárolóhálózatokat. 
Az EtherDrive valójában egy egyszerű 
modul, egyik oldalról egy ATA felüle- 
tű merevlemezt lehet csatlakoztatni 
hozzá, másik 
oldalról pedig 
ethernetháló- 
zathoz csatla- 
kozik. A mo- 
dulokat erre 

a célra készült 
állványokra 
lehet helyezni, 
egy-egy polcra 18 meghajtó fér el 

- végeredményként egy átlagos mé- 
retű szekrényben akár 60 IB-nyi tá- 
rolókapacitással is rendelkezhetünk. 
A modulok a nyílt szabványként is- 
mert AIA ethernet felett (AIA over 
Ethernet, AoE) protokollon keresztül 
érhetők el, normál blokkos eszköz- 
ként. (AoE illesztőmodul Linux alá is 
létezik.) Segítségükkel gyakorlatilag 
tetszőleges méretű, könnyen bővíthe- 
tő és méretezhető tárolórendszerek 
építhetők ki, az egyes modulok szük- 
ség szerint egyedi és RAID-módban 





is használhatók. 
2 http:/www.coraid.com 


Medgyesi Zoltán 
(mz€rettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
autózni és bográcsban főzni. 








2004. június 





0 Kiskapu Kft. Minden Jog fenntartva 





ETLÉSL ELT 


0 Kiskapu Kft. Minden Jog fenntartva 


10 


Ni újság a rendszermag fejlesztése körül? 


A 2.6.0-s számot viselő rendszermag megérkezett, 
nagyjából a határidőre. A Linux fejlesztése során 

ez az első alkalom, hogy az üzembiztos változat az 
előre kitűzött időpontban jelenik meg, és sajnos az 
egyéb nyílt forrású fejlesztésekre sem jellemző az 
effajta pontosság. Noha a legtöbben már elfogad- 
ják Linus forvalds nézetét: az önkéntes fejlesztők 
bevonása Jobb minőségű kódot és tempósabb mun- 
kát eredményez, a határidők betartása továbbra is 
rózsaszínű álom marad. 

A 2.6.0-s változat esetében Linus igyekezett ke- 
ményen betartani a befagyasztások és az egyéb 
munkák határidejét, ám ezt csak úgy lehetett elérni, 
hogy a különféle összetevőket pontosan egyszerre 
készítették el. Egyelőre tehát nincs általános 
csodamódszer. A karbantartás feladata a 2.6-os fa 
esetében - a jelek szerint — túlnyomó részt Andrew 
Morton feladata, ahogy a 2.4-es fánál ezt a munkát 
Marcelo fosatti, a 2.2-esnél pedig Alan Cox vállalta 
fel. Tulajdonképpen egyelőre nem teljesen tiszta, ki 
felel a 2.6-os fa karbantartásáért. Úgy látszik, hogy 
Andrew hozza meg a döntéseket, a kiadások mégis 
Linus neve alatt jelennek meg. Lehet, hogy Linus és 
Andrew szoros együttműködése egészen a 2./7-es 
ág megjelenéséig megmaraa, ám pillanatnyilag a 
karbantartás minden eddigi üzembiztos változat 
sorsánál bizonytalanabb. Kíváncsian várom, vajon a 
2.7-2.8 változatok megjelenése között vajon hogyan 
oldódnak meg ezek a kérdések. 

A múlt hónapban azt Írtam, hogy Marcelo losattinak 
a 2.6-os sorozat megjelenése miatti teljes befa- 
gyasztásra vonatkozó terve okán az XFS várhatóan 
nem kerül be a 2.4-es fába. Az XFS a végső zárás 
előtt mégis a 2.4-es sorozat része lett. Ez a lépés 
nem kis részben a fejlesztők felzúdulásának volt 
köszönhető, ugyanis az XFS volt az egyetlen olyan 
fontosabb naplózó fájlrendszer, amely még nem 
szerepelt a 2.4-es ágban. Marcelo emellett koráb- 
ban jelezte, hogy az XFS akkor kerülhet be a fába, 
ha elkészült. Végül Marcelo csak úgy engedte be 

a kódot a 2.4-es fába, hogy előtte harmadik fél által 
gondosan ellenőriztette. Nekünk a legfontosabb a 
végeredmény, mégpedig az, hogy az XEFS teljesítette 
az előírt határidőt, a további munkák célja pedig 


A SOLIS névadója 


Jon "maddog" Hall és Cesar Brod először 1999-ben 
találkoztak. 2001-ben ellátogatott a Univates egye- 
temre, ekkor javasolta az ott dolgozó csapatnak, 
hogy munkájukat más egyetemekkel Is ismertessék 
meg. Ő lett a SOLIS keresztapja. 


Cesar Brod 


Linuxvilág 


— a befagyasztástól függetlenül — működésének to- 
vábbi finomítása. Meddig tart a lelkesedés, azt majd 
meglátjuk. 

lan Kent - legalábbis a dolgok pillanatnyi állása sze- 
rint — elfogadta a DevE-S karbantartásának feladatát. 
Döntése éles fordulatot jelent a korábbi folyamatok- 
hoz képest, ezeket látva a DevF-S csendes kiszenve- 
désére, illetve valamilyen más, hasonló megoldással 
— mint az udev - való leváltására lehetett számítani. 
Tény, hogy Greg Kroah-Hartman, pontosan Ilyen 
lépésre számítva, rendszeresen közzétette az udev 
újabb és újabb kiadásait. De ne feledjük, hogy a 
DevHS, hiába vannak akár javíthatatlannak bizonyuló 
hibái, képes olyan szolgáltatásokat nyújtani, melye- 
ket semmilyen más rendszer nem kínál. lan és 
sokan mások úgy gondolják, hogy a DevFS-nek a 
rendszermagban kell maradnia, hibáit pedig ki kell 
javítani, bármilyen nehéznek is tűnjék ez a feladat. 
lan tehát, legalábbis egyelőre, elfogadta a meg- 
bízást. Érdekes lesz látni, hogy a rendszermag más 
fejlesztői, név szerint Alexander Viro (a DevEFS egyik 
különösen elszánt gyűlölője), hogyan fogja értékelni 
a váratlan fordulatot. 

Yasunori Goto olyan kódrészeken dolgozik, melyek a 
RAM üzem közbeni csatlakoztatását és leválasztását 
teszik lehetővé. Eddig elsősorban NUMA gépekre 
fejlesztett, de a közeljövőben IA-64 és IA-32 alapú 
gépekre Is szeretne átültetést készíteni. Az asztali 
gépeken egy ilyen szolgáltatás inkább csak érdekes- 
ség, a kiszolgálók rendszergazdái számára viszont 
kisebbfajta megváltás, mely segít csökkenteni a 
vállalati rendszerek leállási idejét. Ezzel a fejlesztés- 
sel a valóban könnyen méretezhető, egymásra 
építhető rendszerek világa is közelebb kerül hoz- 
zánk. Képzeljünk el egy felölthető számítógépet, 
amely további két processzorral bővül, amikor 
felhúzzuk a cipőnket. Nem hiszem, hogy Yasunori Is 
ilyen futurisztikus dolgokon töri a fejét, ám a RAM- 
lapkák (RAM chip) üzem közbeni csatlakoztatása 
sok érdekes lehetőséget tár majd elénk. 


Zack Brown 
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Ők mondták 





1. A CPUBuilders linuxos PC-inek induló ára a Sams Club 
oldalán: 256,68 dollár 
2. A Microtel linuxos PC-jének induló ára a Wal-Martnál: 
199,98 dollár 
3. Egy 2.66 GHz-es, Linux minősítéssel rendelkező, 
Debian Linuxot futtató hordozható gép ára: 1749 dollár 
4. A Japán által a Linux-fejlesztők támogatására fordított 
dollármilliárdok száma: 8,3 
b. A nyílt forrású fejlesztésekben részt vevő tajvani 
vállalatok száma: 20 
6. A tajvani fejlesztők által előállított nyílt forrású 
programok értéke millió dollárban számolva: 34 
7. A tajvani kormány ennyi millió dollárt fordít a nyílt forrású 
programfejlesztés népszerűsítésére: 3,4 
83. A tajvani kiszolgálók ekkora százaléka futtat jelenleg nyílt 
forrású programokat: 10 
9. A tervek szerint 2007-ben a tajvani kiszolgálók ekkora 
százalékán fognak nyílt forrású programok futni: 30 
10. A tajvani személyi számítógépek ekkora százaléka futtat 
jelenleg nyílt forrású programokat: 0,2 
11. A tervek szerint a tajvani személyi számítógépek ekkora 
százaléka fog nyílt forrású programokat futtatni: 5 
12. Ennyi milliárd dollárt fizetett ki a Sun Microsystems a 
Cobalt Networks részvényeiért 2000-ben: 2 
13. A Sun által 2004. február 19. után is tovább gyártott 
Cobalt-termékek száma: 0 
14. A tervek szerint Kínában ennyi millió példányban fogják 
telepíteni a Linux alapú Sun Java Desktop Systemet: 200 
15. A Sun Java Desktop Systemet 2004. januárjától kezdve 
minden évben legalább ennyi példányban fogják 
telepíteni: 500 000 
16. A Sun Java Desktop Systemet 2004 januárjától 
kezdődően évente legfeljebb ennyi példányban fogják 
telepíteni: 1 millió 
17. A Sun tervei szerint ennyi linuxos PC lesz 
Kínában: 500 millió 
18. A Microsoft Office — OpenOffice.org átállással elérhető 
költségmegtakarítás százalékos aránya: 60-/0 
19. Saő Paulo 72 teleközpontját hetente ennyi ember veszi 
igénybe: 150 ezer 
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A Linux Journal 
honlapján számtalan 
gond megoldásához 

találhattok további 
segítséget. A Sunsite 
tüköroldalait, a gyakori 
kérdéseket és az egyéb 

útmutatásokat a 

5www.Iinuxjournal.com 
honlapon olvashatjátok 
el. A rovatban közzétett 
válaszokat Linux-szak- 
értők kis csapata készí- 
tette el. További kérdé- 
serteket szívesen fogad- 
Ják (angol nyelven) a 

5 www. Iinuxjournal.com/ 
[-Issues/techsup. html 
címen, ahol csak egy 
kérdőívet kell kitöltene- 
tek, de a bts(ossc.com 
címre levelet is írhattok. 
A levél tárgyában 
szerepeljen a ,BIS" 
kulcsszó. 
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A hónap szakmai tanácsai 


A finclude használata 

A check regionO hívással próbálok kapukat elérni, 
s ennek érdekében a kódomba foglaltam a /linux7 
resource. c fájlt. Amikor azonban megpróbálom le- 
fordítani a programot, a következő hibát kapom: 


In file included 
/usr/include/linux/sched.h 
/Vinux/resource.c 
/usr/include/linux/timex.h :field "time" 
has incomplete type 


A time egy timeval típusú adatszerkezet, megadá- 
sa a timex.h fájlban található. Kérlek, segíts, mi a hi- 
ba oka és mi lehet a megoldás. 

Ashutosh Sharma, catchwavesingyahoo.com 


A resource.c egy forráskódfájl, ez tartalmazza az 
összes függvény megvalósítását, köztük azét is, 
amelyet használni próbálsz. Szerintem inkább 

a clinux/ioport.h: fájlt kellene befoglalnod, eb- 
ben szerepelnek a függvények megadásai -— és nem 
megvalósításal. 

Chad Robinson, crobinsonerfgonline.com 


Nagyméretű képek nyomtatása a Gimp alól? 
A Gimpet használom szinte minden képszerkesztési 
feladatra, és nemrég készítettem néhány nagymére- 
tű, például 61 x61 cm-es képet. Elsősorban vázlat- 
ként használom őket, mielőtt végleges festményt 
készítenék vászonra. Van egy HP 5650 típusú nyom- 
tatóm, ami természetesen nem tud ilyen nagy la- 
pokra nyomtatni. Ezért nyomtatáskor sajnos csak 

a kép bal felső sarka kerül papírra. Szeretném meg- 
találni a módját, hogy a teljes képet kinyomtathas- 
sam eredeti méretében, természetesen több normál 
méretű lapra elosztva, melyeket összeragasztanék. 
Létezik ilyen program a linuxos világban, vagy ven- 
nem kell egy HP plottert? Ez azonban jóval drágább 
megoldás lenne. 

Paul Godin, linuxstuff-oIstop.com 


Lehet, hogy félreértek valamit, de elég egyszerűnek 
tűnik a megoldás. Darabold fel a képet több részre, 
majd egyenként nyomtasd ki őket. A Gimp alatt ezt 
kézzel teheted meg, de az ImageMagick eszköz- 
készlet segítségével parancsfájlt is készíthetsz hoz- 
zá. A programkészletben található egy convert(1) 
nevű eszköz is, amellyel a képeket nyomtatásra al- 
kalmasabb - például PostScript vagy PCL - formá- 
tumra hozhatod, illetve részeket vághatsz ki belőlük. 
Használatáról a hozzá tartozó súgóoldalon olvas- 
hatsz bővebben, bár ha jól emlékszem, a -crop 
kapcsolót kell használnod. 

Chad Robinson, crobinsonerfgonline.com 
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Nyomtasd ki az anyagodat egy PostScript fájlba, 
majd a következő programmal oszd fel több oldalra: 
www. ctan.org/tex-archive/supportposter. A lapokra 
külön jelzéseket Is nyomtat, ezek alapján szétvágha- 
tod és egymáshoz illesztheted őket. 

Marc Merlin, marc bts0google.com 


Tűzfal Red Hat 9-es rendszerből 


Van egy gépem két ethernetkártyával, melyből tűzfa- 
lat szeretnék építeni. Az útválasztást már engedé- 
lyeztem rajta. Az FWbuilder 1.1.1-es és a Red Hat 
9-es változatát futtatom rajta. Kérdésem a rendszer- 
mag útvonaltáblájára vonatkozna. A külső cím az 
ethO0 csatolón 192.168.1.2, a belső cím pedig az 
eth1 csatolón 172.10.10.252. Az eth0 esetében az 
alapértelmezett átjárónak 192.168.1.1-nek kell len- 
nie, a rendszermag azonban a 192.168.1.2-t teszi 
alapértelmezetté, és nem ereszti el az útvonalat. Át- 
irányítottam a 192.168.1.0-ra, de az eth0-nál megáll 
a forgalom, és nem halad tovább a 192.168.1.1 felé. 
A belső oldallal nincs gond. Azon túlmenően, hogy 
újrafordítom a rendszermagot, hogyan tehetném 

a 192.168.1.1-et alapértelmezett átjáróvá? 

Joe Golden, jJgolden30csc.com 


írd át a /etc/sysconfig/network-scripts/ifcfg-ethO fájlt. 
Egy GATEWAY-"192.168.1.1" tartalmú sort kell hoz- 
záadnod, majd a service network stop/service 
network start parancsokkal újra kell indítanod a há- 
lózati szolgáltatást. 

Felipe Barousse Boué, fbarousseoplensa.com 


Váltás meglévő X-munkamenetek között 


Hogyan futtathatok egyszerre több XX-munkamene- 
tet? legyük fel, hogy rendszergazdaként jelentkezek 
be, nyomok egy CTRL-ALT-F2 billentyűkombinációt, 
kiadom a startx -- :1 parancsot, elindul az X, min- 
den remekül működik. A CTRL-ÁLT-F-7 kombinációval 
visszalépek, továbbra Is minden rendben. Amikor 

a CTRL-ÁLT-[-2-t újra lenyomom, akkor az ottani X már 
elszállt. Az F/7-en futó viszont továbbra is megvan. 
Létezik olyan parancs, amivel az [-2-n Is életben tart- 
hatom az X-et, miközben Ide-oda váltogatok? 

Bjarni Valsson, bjarniveohotmail.com 


Az X nem az [-2-n (pty 2) fut. Minden X-példány saját 
pty-t indít, ezért lehet a pty 7-re váltani. Ha vissza- 
lépsz a pty 2-re, akkor valójában a háttérbe küldöd 
az X-et (CTRL-Z, majd a bg parancs), és az adott kon- 
zolt más feladatokra használod. Ha újabb X-példányt 
indítasz, miközben már fut egy, akkor újabb pty jön 
létre, esetedben ez a 8-as. Erre az X-példányra 

a CTRL-ALT-F8 billentyűkombinációval léphetsz vissza. 
Chad Robinson, crobinsonerfgonline.com 


Cinüax dodrnal 2004. ápriis, 120. számi 


e ALL 





Új termékek 


Altix 350 


Az SGI Altix 350 ki- 
szolgálója 1—16 da- 
rab 64 bites Itanium 
2 processzort (nor- 
mál vagy alacsony 
feszültségű típust) és 
összesen legfeljebb 
192 GB megosztott 
memóriát tartalmaz- 
hat. A 350-es másod- 
percenként 6.4 GB 
továbbítására képes 
SGI NUMAIiInk össze- 
köttetéseket használ. Alkalmas 

a független méretezésre pro- 
cesszorok, megosztott memórla 
és be/kiviteli (I/0) eszközök tekin- 
tetében egyaránt, szabványos há- 
zába különféle bővítőmodulok 
építhetők be, így a legkomolyabb 
igényeket támasztó műszaki alkal- 
mazásokban is megállja helyét. Az 
SGI a 350-es tartozékaként a Pro- 
Pack programot kínálja, amely 

a normál Linux-terjesztésekben 
megtalálható rendszer-, adat és 
erőforráskezelő-szolgáltatásokra 
épülő eszközöket, könyvtárakat és 
teljesítménynövelő megoldásokat 
kínál használójának. 

2 http:/Awww.sgi.com 


IVR100B 


Az IVR100B egy állványra szerel- 
hető távközlési alkalmazáskiszol- 
gáló felhasználói beavatkozást 
igénylő, GNU/Linuxra és Bayonne- 
ra épülő, beszédalapú ügyfélrend- 
szerek (Interactive Voice Response, 
IVR) üzemeltetéséhez. Alapeset- 
ben négykapus Pike Inline GT be- 
szédkártya Jár hozzá, melyet leg- 
feljebb 24 kapuig lehet bővíteni. 
Az IVR100B-ben Pentium osztályú 
egylapkás számítógép és legalább 
32 MB RAM található, beépített 
USB- és 10/100 Mb/s sebességű 
ethernetcsatolóval rendelkezik, va- 
lamint Ouantum Fireball LM IDE 
merevlemez tartozik hozzá. A gép 
mellé IVR-alkalmazásokat Is ka- 
punk, amelyek adatbázisokkal és 
web- és levélkiszolgálókkal képe- 
sek kapcsolatot teremteni. 

2 http:/Avww.ostel.com 
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Desktop/LX Pocket PC Edition 


isz] va! A lycoris beje- 
lentette Linux 
operációs rend- 
szerének kézIi- 
gépekre sza- 
bott, Desk- 
top/LX Pocket 
PC Edition nevű 
változatát. A teljes egészében nyílt 
szabványokra épülő kiadás a veze- 
tékes, az USB, az infravörös és 
302.11b alapú hálózati kapcsolato- 
kat egyaránt támogatja. leljes érté- 
kű személyi adatkezelő program- 
gyűjtemény Jár hozzá, teljes mér- 
tékben támogatja a HIML és 

a CSS 4 szabványokat, továbbá ké- 
pes a POP3 alapú levélletöltésre, 
hangok, mozgóképek és médlafo- 
lyamok lejátszására. Az adatokat 
meghatározott jeleken alapuló kéz- 
írással, képernyőn megjelenő bil- 
lentyűzettel, magával az érintőkép- 
ernyővel, prediktív módon (pick- 
board) és hagyományos billentyű- 
zeten keresztül vihetjük be. 

A Desktop/LX Pocket PC Edition 
bizonyos StrongáArm és XScale 
processzorokat és lapkakészlete- 
ket támogat. 

2 http:/Awww.lycoris.com 





Tripwire for Network 
Devices 3.0 





A Tripwire for Network Devices 
3.0 egy több gyártó termékelt Is 
támogató, hálózati beállítások ke- 
zelésére, pontosabban a hálózati 
elemeket érintő változások köz- 
ponti felügyeletére, figyelésére és 
jelentésére használható alkalma- 
zás. A Iripwire nemcsak a hetero- 
gén környezetek támogatására ké- 
pes, de változatkövetésre is alkal- 
mas, vagyis minden eszköz beállí- 





tásalt archiválja, a mentett adato- 
kat pedig változás észlelésekor 
önműködően kiegészíti. A Iripwire 
for Network Devices akár több tíz- 
ezer csomópont kezelésére Is ké- 
pes, a csomópontokat logikai cso- 
portokba sorolhatjuk. A jelszavak 
és jogosultságok kezelése érdeké- 
ben egybeépül a felhasználók hite- 
lesítését végző, a hozzáférésüket 
ellenőrző és erőforrás-használatu- 
kat számlázó alkalmazásokkal. 

A Tripwire alapszintű helyreállítá- 
sokra, az épség valós idejű ellen- 
őrzésére és az előírások betartásá- 
nak vizsgálatára Is képes. 

2 http:/Awvwwi.tripwire.com 


REALbasic 5.5 


A REAL basic 5.5 
egy fejlesztői 
eszköz, amellyel 
több géptípu- 
son - Linux, 
Windows és 
Mac - Is futtat- 
ható alkalmazá- 
sokat készíthe- 
tünk. A REAL basic része a VB 
Project Converter eszköz, amellyel 
táblákat, űrlapokat és programkó- 
dot lehet REAL basic alá átemelni; 
így állíthatók elő a Linux vagy 
Macintosh alá szánt programvál- 
tozatok. A REAL basic 5.5 x86 
Intel gépeken a Red Hat Enter- 
prise és a SuSE-terjesztéseket tá- 
mogatja, de bármely más terjesz- 
téssel is használható, ha abban 
megtalálhatók a szükséges GIK-- 
2.0-s és a CUPS könyvtárak. 

A program távoli hibakeresésre Is 
alkalmas, Így a linuxos alkalmazá- 
sok hibái Windows vagy Mac alól 
is megkereshetők. Az 5.5-ös vál- 
tozathoz további bővítmények 
(plugin) is beszerezhetők, így to- 
vábbfejlesztett felhasználói felüle- 
tek, javított együttműködés az MS 
Office-alkalmazásokkal, kiterjesz- 
tett Mac OS X támogatás, jobb 
adatbázis-elérés, SOAP- és XML- 
támogatás és további APl-k. 

2 http:/Avww.realsoftware.com 
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Linux a légiforgalmi irányításban 


A Linux nélkülözhetetlen a Szövetségi Légügyi Hivatal légi irányító programjához. 


ok ember szerint a Linux még nem nőtt fel a légi irá- 
nyítás feladataihoz, de a valóságban felkészült, oly- 
annyira, hogy már használják is. Nemrégiben részt 
vettem egy projektben, amely a FAA (Szövetségi Légügyi Hi- 
vatal) Common ARIS programját (3 http:/wwwl1l.faa.gov/ 
ats/atb/Sectors/Automation/CommonArts/index.htm) ültette 
át Linuxra. 

Amikor a légi irányító rendszerekre gondolunk, többnyire 
egy kerek képernyőn pásztázó sugarat látunk magunk 
előtt. Kevesen tudják miként néz ki valójában a Radar an- 
tennarendszer. A Radar antenna és a képernyő között jó 
néhány számítógép teszi könnyebbé a kapcsolattartást. Di- 
gitális jelfeldolgozó processzorok (Digital Signal Processors, 
DSP) találhatók mind az antenna épületében, mind a vezér- 
lőrendszerben. Írásunk bemutatja, hogyan működik a ve- 
zérlőrendszer, és hol alkalmazzák a Linuxot. 


Történelem 

Az Automated Radar Terminal System (ARIS, azaz ön- 
működő Radar terminálrendszer) 1964-ben állt munkába, 
Univac számítógépeken. A rendszer 1973-ban került orszá- 
gos felhasználásra az Egyesült Államokban. Az eredeti szá- 
mítógépeket felújították és mind a mai napig használják. 
Számos nagy központ már a 80-as években átköltözött az 
Univacról a mikroprocesszoros rendszerekre. Az összes Örö- 
költ ARIS programot átültették vagy C-ben újraírták, hogy 
a valós idejű LynxOS alatt legyenek futtathatóak. 

A LynxOS-re való költözés nem volt véletlen, mivel ez Posix 
alapokat nyújtott, ami lehetővé teszi a további átültetést. 
Ezenkívül a LynxOS használata megengedte a fejlesztők 
számára, hogy a használni kívánt mikroprocesszort kivá- 
laszthassák. Kezdetben a program Motorola 68K-n futott, 
jelenleg PowerPC-n működik. 


Kiépítés 

A Common ARIS rendszer egy erősen elosztott, hálózatos, 
többszálú, valós idejű rendszer. A teljes megbízhatóság elő- 
feltétel. Kettős hálózatot használnak, és normál körülmé- 
nyek között minden megadott feladatra két tartalék kerül 
kijelölésre. A programot úgy tervezték meg, hogy adott al- 
rendszer néhány szolgáltatását át tudja venni egy másik al- 
rendszer. 

A Radar adatai soros vonalakon érkeznek be a követő pro- 
cesszorokhoz (track processzor — TP). Általában négy soros 
vonal megy minden Radarból mindegyik IP-hez. A Radar 
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Egy vezérlő Atlantában 


adatok tartalmazzák a nyers Radar jelet, a válaszadó 
(transponder) válaszát (minden repülőgépnek van egy vá- 
laszadója, amely egy azonosítószámot és magassági adatot 
küld vissza minden alkalommal, amikor a Radar letapogatja 
a gépet), valamint az időjárási adatokat. Általában ugyanaz 
az antenna veszi mindhárom jelet. Bármelyik Radar és vá- 
laszadó adata bármelyik három soros vonalon mehet, míg 
az időjárás a saját soros vonalán kerül továbbításra. 

A IP legalább két alrendszerre van osztva: a soros üzenet- 
összeillesztőre és a pillanatnyi nyomvonal-feldolgozóra. 

A soros üzenet-összeillesztő minden üzenettípust (nyers 
Radar, válaszadó és időjárás) hálózati üzenetté alakít át. 

A nyomvonal-feldolgozó az összetartozó Radar és válasz- 
adó üzeneteket (célokat) egyetlen nyomvonallá dolgozza 
össze. A nyomvonal a repülőgép ismert története. A célok 
lehetnek Radar- vagy válaszadó jelek, vagy mindkettő. 
Amint egy célpont összefüggésbe kerül egy nyomvonallal, 
egy újabb nyomvonalüzenet kerül a hálózatra. 

Az üzeneteket általában a hálózaton sugározzák, vagyis 

a hálózat minden pontjára eljutnak. Mindkét fővonalon 
UDP használatával kerülnek küldésre, és minden üzenet- 
nek egyedi csomagazonosítója van. A hálózaton az összes 
számítógép figyeli mind a két fővonalat, és minden cso- 
magazonosítót, valamint az őket küldő egyedi hálózati azo- 
nosítót feljegyezi. Ha rés támad a csomagazonosítók sorá- 
ban, bármely készülék kérhet újraküldést. A duplikált cso- 
magazonosítókat azonban mellőzi, mert feltételezi, hogy 
ez az üzenet a másik fővonalon érkezett vagy egy másik 
készülék kért újraküldést. 


Minden rendszernek szívveréseket kell sugároznia a háló- 
zaton. Ha egy szívverés kimarad, az azt feltételezi, hogy 

a hozzá tartozó rendszer nem működik, és többi rendszer 
egyike üzenetet küld, hogy a tartalék rendszer vegye át 

a feladatát. 

A következő, aki a hálózati üzeneteket feldolgozza, az általá- 
nos processzor (Common Processor - CP). A CP számos fel- 
adatot lát el, például párosítja a repülési terveket a nyomvo- 
nalakkal, ütközési riasztásokat (Conflict Alerts, CA) és a leg- 
kisebb biztonságos magasság riasztásokat (Minimum Safe 
Altitude Warning, MSAW) küld, valamint néhány Common 
ARIS rendszer szívverését is figyeli. A CP legfontosabb fel- 
adata a légisebesség és nyomvonal irányának meghatározá- 
sa. Ezeket az adatokat összevetve más nyomvonalak sebes- 
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Teljesen digitális ARTS kijelző. Az ACD-k (Jobb oldalon) fogják 
leváltani ezeket a vektorkijelzőket. Minden tekerőgomb menüben 
található a kijelzőn 


ségével és irányával a CA állapítja meg a lehetséges ütközés- 
veszélyt. Amennyiben ütközésveszélyt állapít meg, a CP egy 
CA üzenetet sugároz a hálózatra, megjelölve a feltételezett 
összeütközésben érintett repülőgépeket. Amikor egy repülő- 
gép 300 csomóss - kb. 5 mérföld percenként -— sebességgel 
halad, fontos egy vagy két percre előre tekinteni. 

Az MSAW helyszínre illesztett térképet használ a táj dombor- 
zatának ismeretéhez. A domborzathoz nemcsak a dombok és 
hegyek, hanem a tornyok és magas épületek is hozzátartoz- 
nak. A válaszadóval (transponder) felszerelt repülőgépek ese- 
tében az MSAW rendszer figyeli a helyzetet és magasságot, 
amiből megállapíthatja, hogy a gép esetleg túl alacsonyan 
száll. Ha egy repülőgép túl alacsonyan tartózkodónak találta- 
tott, a rendszer egy MSAW üzenetet sugároz a hálózatra. 

Az utolsó fő rendszer a hátsó szobában (back room) 

a rendszer megfigyelő és irányító (System Monitor and 
Control -— SMC). Az SMC fő célja a többi rendszer megfi- 
gyelése és irányítása. Ez egy átjáró az SMC megjelenítő 
PC-re, ami grafikus kezelőfelület a hálózat és annak pilla- 
natnyi állapotának megfigyelésére. A pillanatnyi állapot jel- 
zi, hogy egy-egy rendszer működik, nem működik, várako- 
zik vagy üresjáratban üzemel. Ha egy szívverés kimarad, 
az SMC utasítja valamelyik várakozó rendszert a feladat át- 
vételére. A rendszer kezelője bármikor kézzel is átkapcsol- 
hat, új programot tölthet be vagy újraindíthatja a rendsze- 
reket, mindezt erről a PC-ről teheti meg. Az SMC emellett 
rögzíti a hálózaton átmenő összes adatot. 
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Amikor a légi irányításról van szó, a legtöbbünk pusztán 

a kijelzőkre gondol: egy szoba tele kerek kijelzőkkel és az 
őket bámuló fehér inges fickókkal. Egyre több helyen hasz- 
nálnak nagy, 20"-os, szögletes, színes kijelzőket. Az új színes 
kijelzők 2048 x 2048 képpontos X Window megjelenítők. 

A kijelző-feldolgozó program (Display Processing Software 
- DPS) kialakítása olyan, hogy a darabjait bármilyen kijel- 
zőtípushoz fel lehet használni, például az olyan színes, 
szögletes kijelzőnél, mint egy ARTS Color Display (ACD), 
vagy a kerek vektorkijelzőnél, mint a Full Digital ARTS 
Display (FDAD). 

A DPS fogadja a sugárzott üzeneteket és megjeleníti a meg- 
felelő képet a rendszer állapotától függően. Normál üzem- 
ben a kijelzés magában foglalja a nyomvonal és az irány 
történetjelölését, egy részleges és teljes adatblokkot, vala- 
mint a különböző rendszerek állapotát. 

A CP-től származó repülésterv-információ üzenet a teljes 
adatblokkban jelenik meg, közel ahhoz a repülőgéphez, 
amelyikhez a IP már elkészítette a nyomvonalat. Az SMC 
átfogó állapota szintén megjeleníthető. A hálózat egyszerre 
egy vagy akár több száz kijelzőt is használhat. 

Ráadásul minden rendszer egy vagy több processzoron fut- 
hat. Ha a CPU teljesítménye elég nagy, minden rendszer és 
alrendszer egyetlen processzoron futhat. 


Atültetés 

Kezdetben az átültetés oka az volt, hogy lehetővé tegyük 

a fejlesztők számára a kipróbálást és a hibakeresést az aszta- 
li számítógépükön, mielőtt a célgépen kipróbálnánk. A cél- 
gép LynxOSI futtató VME vázban lévő Motorola OEM kár- 
tyákból áll. A rendszerek viszonylag drágák, ezért sem 

a FAA, sem a Lockheed Martin nem akart feleslegesen be- 
gyűjteni belőlük. Ehelyett szinte folyamatosan különféle 
tesztrendszereket használnak az összevont kipróbálásokra 
és a fejlesztésre. Mivel az IS osztály Microsoft Windows NT 
PC-ket adott a fejlesztőknek, megpróbálták a programot át- 
ültetni NI-re. Az átültetés nagy része készen volt, amikor 
dolgozni kezdtem a cégnek. Néhány dolog kipróbálására az 
NI-t jól lehetett használni. Egy átalakító réteg tette lehető- 
vé, hogy a Posix-szálak, a fájlműveletek és a grafika ugyan- 
úgy nézzen ki, mint a célrendszereken, emiatt ezek kipró- 
bálására alkalmatlan volt. 

Amikor a Lockheed Martinnál kezdtem, az üzenetréteg cso- 
porthoz kerültem, amely a kapcsolattartással, szálkezeléssel 
és a fájl B/K (I/O) kezeléssel foglalkozott. Alapvetően egyik 
tesztünket sem lehetett asztali gépen elvégezni, ezért a cél- 
eszközt kellett használnom. Kezdetben egy mellékprojekt is 
futott, pusztán azért, hogy megbizonyosodjunk megvalósít- 
hatóságáról, s én egy öreg (200 MHz-es Pentium) PC-t kap- 
tam a fejlesztéshez. 

A kódok többsége rendben lefordult, bár akadtak gondok 

a Posix-szabvánnyal. A LynxOS - a 2.4-es és 3.0-s — egy ré- 
gebbi szabványt alkalmaz, míg a Linux a jelenlegit használ- 
ja. Kezdetben a 2.2-es rendszermagot futtató Red Hat 7-esen 
végeztem a fejlesztést, de ez nem támogatta a kinevezett 
jelzőket (named semaphores) és a kinevezett memóriasza- 
kaszokat. Egy olyan elosztott rendszerben, mint a miénk, 
könnyebb a processzoron belül állandó neveket használni, 
mint egyéb kapcsolattartási módszert használni, és meg- 
tudni azt, hol találhatók a megosztott memóriaterületek és 
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Képernyőfotó a 8 bites VGA Linux DSP programról. Összehasonlítva az 
ACD kijelzővel, csak a teljesen barna időjárás a különbség. A kék 
előzménycsíkok hasonlóak, a zöld válaszadó és Radar képek ugyanazok. 
A menü átlátszó a térképen, de az időjáráson nem 


jelzők. Összeférceltem egy kinevezett memória-megfelelő- 
ségi réteget (named shared memory compatibility layer) és 
egy orosz webhelyen találtam egy kinevezett jelző megfe- 
lelőségi réteget (named semaphore compatibility layer). 

A fejlesztés során Red Hat 7.1-re váltottam, amely elvileg 
támogatja a kinevezett megosztott memóriát, de megfelelő- 
ségi gond akadt a glibc és a header fájlok között. A hibát 
megleltem a forrásban és egy feljegyzést küldtem a rend- 
szermag-levelezőlistára. Hogy bárki, bármilyen javítás nél- 
küli Red Hat-változattal dolgozni tudjon, a kódban hagy- 
tam az általam összefércelt változatot. 

A céleszköz mind nagy endian típusú (Motorola 68K és 
PPC), a Linux PC pedig x86 kis endian, ezért szükségem 
volt némi bájtfordításra, hogy az egész rendszer működjön. 
Sok fájl bináris formában tárolt (térképek, adaptációk stb.). 
A hálózati rétegben már volt beépítve egy bájtfordító szer- 
kezet és jól is működött. 

Amint az összes üzenetkezelő kód lefordult és futott, szük- 
ségem volt egy alkalmazásra. Az FAA egyetértett, hogy fek- 
tessük le a IP CB SMC és D$P rendszerek további fejleszté- 
sének alapjait az asztali kipróbáláshoz és hibakereséshez. 
Az összes rendszert jól át lehetett ültetni, de a DSP-nek 
akadtak gondjai az X-megjelenítéssel. Normál esetben 

a nagy 2048 x 2048 képpontos megjelenítők egyedi eszközö- 
kön futnak, két vagy három álszínes fizikai síkon. Ha a me- 
nük és a térképek a hátsó síkon kerülnek kirajzolásra, az 
időjárás a következő síkon, a repülőgépek pedig a legfelső 
síkon, nem szükséges a teljes kijelzőt újrarajzolni egy repü- 
lőgép elmozdulásakor. Ahhoz, hogy ez a síkos megoldás 
működjön, a színtérkép három részre lett osztva. Az álszí- 
nes (8 bites) megoldás minden síkon korlátozza a használ- 
ható színeket. A térkép és menüsík kapta a fehér színt, az 
időjárás a barnát, az elsődleges megjelenítő síknak pedig 
78 szín jutott. 

Emiatt szükség volt a színtábla módosítására, mivel normál 
esetben az elsődleges kijelző 250 színt használt. A nagy ki- 
jelzőnek van egy animált elhalványuló pásztázó vonala, 
amely emulálja a vektorkijelző elhalványuló foszforát. 
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Az irányító egy ACD-t figyel 


Ennek az animációnak a megvalósítása 128 színcellába ke- 
rül. Ehhez az alkalmazáshoz egyetlen cellát használtam ani- 
máció nélkül. Lenyűgözően néz ki. Kikeresve a hasonló pi- 
rosakat, zöldeket, sárgákat, kékeket, fehéreket és szürkéket, 
megnyirbáltam a színtáblát 78 színre. 

Amint mindezzel elkészültem, kaptam egy kétsíkú video- 
kártyát, hogy lássam, még ekkor is működik-e a rendszer. 
Egy fordítási idejű zászló (compile time flag) átállításával az 
egész dolog működött. A kétsíkú kártya az időjárást, a tér- 
képeket és a menüt ugyanarra a síkra tette. 

Két dolog is történt etájt: az FAA-nak leszállítottam a Linux- 
kódot, és néhány másik fejlesztőnek az a feladat jutott, hogy 
a cél PowerPC-n tegye futtathatóvá a Linuxot. Az FAA talált 
néhány frissítést, amit én nem vettem fel az alapkóddal, és 
együtt dolgoztunk rajtuk. A többi fejlesztő úgy találta, hogy 
az én legtöbb fi fdefs-em a Linuxhoz és nem a számítógép- 
hez kapcsolódik. Emiatt visszatartottam az összes változtatá- 
somat és elkészítettem a megfelelő si fdefs-eket mire végül 
az FAA megkapta őket. 

A PowerPC Linux Projekt arra tett kísérletet, hogy az SMC 
által végzett adatrögzítő feladatokat továbbfejlesszük. A je- 
lenlegi rendszer fogyasztói szintű, boltban vásárolható opti- 
kai meghajtókat használ, amelyek nem alkalmasak 24 órás, 
heti hétnapos üzemre. Az új rendszer SAN meghajtókat tar- 
talmaz, amelyek jobban illeszkednek a légiforgalmi irányí- 
tás igényeihez. Bár technikailag sikeres volt, de a projekt 
most szünetel. 

Tavaly tavasszal az FAA használni kezdte a Linuxon futó 
Common ARTS-t egy nem kényes (noncritical) alrendsze- 
ren, egy olcsó átjáró rendszer, amely ARTS adattal látja el 

a többi rendszert. A teljes engedélyezés pedig nemsokára 
bekövetkezhet. 


Cinüxedodrmal 20042 jandat Ti 1 /sszámi 


Iom Brusehaver 

Programozó, aki már a PC előtti korszakban Is 
kódokat írt. Jobbára szerződéses munkákat vé- 
gez. Nős, felnőtt gyermekei, két macskája és 
egy kutyája van. Amikor szép az Idő, repülő- 
gépet épít. 


OffiinellíMi AP 


Hordozható linuxos számítógépet használók, próbáljátok ki a gyors, 
kényelmes helyi alkönyvtár és a kiszolgáló alapú IMÁABP-tároló előnyeit 


egyesítő levelező megoldást. 


okak számára az elektronikus levél az internet leg- 
fontosabb hozadéka. Elektronikus leveleket olva- 
sunk otthon, a munkahelyen, utazás közben - több 
különböző számítógépen. Néha azonban jó lenne ugyanazt 
a levelet mindegyik helyről látni. Előfordulhat olyan eset is, 
ha egy üzenetet az otthoni gépünkről letörlünk, és ugyan- 
azt a postafiókot a munkahelyünkről megnézzük, élő (nem 
törölt) üzenetként látjuk viszont. Még rosszabb, ha egy 
adott üzenetet esetleg csak egyetlen gépről tudunk meg- 
nézni. Néha csak le szeretnénk tölteni elektronikus levele- 
inket hordozható gépünkre, és internetkapcsolat nélkül ol- 
vasgatnánk. Ekkor a helyzet még ennél is összetettebb lesz. 
Akadnak, akik ezeket a gondokat oly módon kísérlik meg- 
oldani, hogy levelezőügyfelükben IMAP-ot használnak. Az 
IMAP azonban hosszadalmasnak és gyengén támogatott- 
nak bizonyulhat, különösen egy lassú kapcsolat esetén haj- 
lamos élvezhetetlenné tenni a levelek olvasgatását. Nemrég 
pontosan ilyen helyzetbe kerültem és roppant bosszús let- 
tem. Szerintem sok program születik oly módon, hogy vala- 
hol egy programozó dühbe gurul. Én jogos felháborodá- 
somban megírtam az OfflinelűMA P-ot. 


Az OfflinelMAP névjegye 
Az OfflinelIMAP-ot arra tervezték, hogy ugyanazt a posta- 


fiókot több különböző gépről tudjuk olvasni, működő 
internet-kapcsolattal vagy anélkül. Kétirányú összehango- 
lást valósít meg, vagyis az általunk véghezvitt összes vál- 
toztatás minden gépünkről ténylegesen látható lesz. Az 
OfflinelMAP működése során kapcsolatba lép egy IMAP- 
kiszolgálóval és a levelezési alkönyvtárainkat összehangolja 
egy sor, helyi gépünkön létrehozott Maildir alkönyvtárral. 
Neve ellenére az OfflinelMAP még akkor is hasznos, ha so- 
ha nem olvasunk leveleket kapcsolat nélküli üzemmódban. 


Az OfflinelMAP telepítése 
Az OfflinelMAáPF-ot egyszerű telepíteni. Látogassunk el az 


OfflinelMAP guux.org/devel/offlineimap címen található hon- 
lapjára és a .deb vagy a tar.gz állományt töltsük le. A Debian- 
felhasználók egyszerűen a dpkg -i offlineimap . deb futtatá- 
sával telepíthetik, azután pedig az apt-get -f install segít- 
ségével ellenőrizhetik a függőségeket és kereshetik meg a hi- 
ányzó elemeket. Ha nem Debiant használunk, győződjünk 
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meg róla, hogy a gépünkön van-e Python 2.2 vagy újabb vál- 
tozata. Ha még nincs Pythonunk, próbálkozhatunk a megle- 
vő terjesztéssel vagy pedig a 5 http:/www.python.org cím- 
ről töltsük le. 

Ha készen állunk az OfflinelűMAP telepítésére, a tar -zxvf 
offlineimap 4.0.2.tar.gz futtatásával kicsomagolhatjuk 
a forrást. Lépjünk be az új könyvtárba és rendszergazda- 
ként adjuk ki a python setup. py install utasítást. Ha el- 
akadnánk, az OfflinelMAP kézikönyv néhány hasznos tele- 
pítési tippet is tartalmaz. 


Alapszintű beállítás 

Az OfflinelMAP beállítását a —/.offlineimaprc állomány tar- 
talmazza. Ez az állomány három részből áll: az első egy ál- 
talános rész, amely az OfflinelMAP átfogó működését sza- 
bályozza. A második a tárolási rész, amely a levelek tárolási 
helyét írja le, valamint a harmadik a hozzáférési rész, ami 
nyilvántartja, hogy két tárolási hely miként van összehan- 
golva. Egy alapszintű, egyszerű beállítás csak kisméretű 
beállítóállományt igényel. Íme egy példa: 


[general] 
accounts - MyMail 

[Account MyMail] 
localrepository - MyMailLocal 
remoterepository - MyMailRemote 


ÍRepository MyMailLocal] 
type -— Maildir 
localfolders -— -/MyMai1l 


ÍIRepository MyMailRemote] 

type - IMAP 

remotehost - hostname. example . com 
remoteuser - my-username-goes-here 
ss] - yes 


Ez a példa egy hozzáférést — MyMail - határoz meg. 

A MyMail postafiókot a hostname.example.com kiszolgálóról 
hangoljuk össze a helyi gépünkön levő —/MyMaiil könyv- 
tárral. Minden távoli alkönyvtár lemásolódik. Amennyiben 
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IMAP-szolgáltatónk nem támogatja az SSL titkosítást, töröl- 
jük az ss] - yes sort. Most futtassuk az offlineimap-ot. 
Ekkor megkérdezi tőlünk a jelszót, azután egyszer elvégzi 
postafiókjaink összehangolását, majd kilép. 


Folyamatos összehangolás 

Amennyiben levélolvasás közben élő internet-kapcsolatunk 
van, az OfflinelMAP segítségével folyamatosan összehan- 
golhatjuk helyi könyvtárainkat a kiszolgálóval. Ehhez egy- 
szerűen egy önfrissítés sort adjunk hozzá a hozzáférési sza- 
kaszhoz. A hozzáférési szakaszunkat például átírhatjuk 
olyan módon is, hogy a következőképpen nézzen ki: 


[Account MyMail] 
localrepository —- MyMailLocal 
remoterepository - MyMailRemote 
autorefresh — 5 


Ha most lefuttatjuk az OfflinelMAP-ot, akkor postafiókjaink 
összehangolását akként fogja végezni mint eddig, de ha be- 
fejezte, a kilépés helyett továbbfut, és ötpercenként össze- 
hangolja a levelezésünket. 


Több hozzáférés összehangolása 

Az OfflinelIMAP több hozzáférés összehangolására is alkal- 
mas. Például lehet, hogy azt szeretnénk, ha leveleket tud- 
nánk olvasni mind a munkahelyi, mind az otthoni levelező- 
programunkkal. Ennek eléréséhez adjunk hozzá egy hozzá- 
férést és két tárolási szakaszt minden hozzáféréshez, eköz- 
ben ügyeljünk rá, hogy egyedi neveket használjunk. Ez- 
után adjuk hozzá a hozzáférést az általános szakaszban lé- 
egymástól. 

A helyi oldalon ügyelnünk kell arra, hogy minden egyes 
hozzáférés összehangolása különböző könyvtárban történ- 
jen, különben keveredés és minőségromlás léphet fel. 


Teljesítménynövelés 

Az OfflineIMAP alapbeállításai, mint a fenti példák is mu- 
tatják, elég óvatosak. Éppen csak üzembe helyeztük, máris 
a lehető legtöbb IMAP-kiszolgálóval igyekszik működni, így 
a néha zavart keltő emelt szintű tulajdonságokat az alapbe- 
állítások letiltják. 

Ha sok alkönytárunk van vagy minden alkönyvtárban sok 

a levelünk, az összehangolási folyamat bizony lassú lehet. 
Ez különösen akkor igaz, ha hosszú válaszidejű internet- 
kapcsolatot használunk, például modemest vagy műholdast. 
Az OfflinelMAPF hogy felgyorsítsa az eseményeket, képes 
egyszerre több kapcsolatot is létesíteni a kiszolgálónkkal. 
Ekkor több feladatot párhuzamosan tud elvégezni. Például 
egyidejűleg tudja végrehajtani három üzenet letöltését és 
két alkönyvtár összehangolását. 

Az OfflinelMAP több beállítási lehetőséget kínál: először 

is az általános szakaszhoz hozzá kellene adnunk 

a maxsyncaccounts - 5 sort. Ez lehetővé teszi az 
OfflinelMAP-nak, hogy egyidejűleg több hozzáférést hangol- 
jon össze, ami majdnem mindig üdvös dolog. Másodszor 
minden egyes hozzáférés távoli részére vonatkozó tárolási 
részekben szabályozhatjuk hány párhuzamos kapcsolatot 
használjon a program. Például a maxconnections - 3 tartal- 
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mú sort hozzáadhatjuk a példánkban szereplő MyMai IRemote 
tárolási szakaszhoz. Ekkor az OfflinelMAP három kapcsola- 
tot tud létesíteni a kiszolgálóval. 

Ha folyamatos összehangolást végzünk a fent leírt 
autorefresh lehetőséggel, egy újabb késedelmi forrás 
jelentkezik. Minden alkalommal, amikor az OfflinelIMAP 
elindít egy hozzáférés-összehangolást, kapcsolatba lép a ki- 
szolgálóval. Amint a szóban forgó összehangolás megtörté- 
nik, megszünteti a kapcsolatot. E kapcsolatok létrehozása 
gyakran lassú. Az OfflinelMAP lehetőséget teremnt arra, 
hogy az összehangolások közötti szünetekben is fennálljon 
a kapcsolat. A gondot az okozza, hogy egyes kiszolgálók 

a hosszú ideig tétlen ügyfelekkel megszüntetik a kapcsola- 
tot. Az OfflinelMAP oly módon oldja meg a nehézséget, 
hogy időről időre küld néhány bitet, s így nem járnak le 

a számlálók. Fenti lehetőségek kiaknázására a következő 
sorokat adjuk hozzá a távoli tárolási szakaszhoz: 
holdconnectionopen - true 

keepalive -— 60 


A keepalive - azaz életben tartás — másodpercekben, míg 
az autorefresh percekben lett megadva. 


Felhasználói felületek 

Az OfflinelMAP-hez több különböző felhasználói felület 
tartozik. A két legelterjedtebb a Tk.Blinkenlights és 

a Curses.Blinkenlights. Az előbbi egy kis grafikus ablakot 
jelenít meg az OfflinelMAP állapotáról X-felületen, az utób- 
bi pedig parancssorban fut és egy tetszetős állapotkövető- 
ben jelenít meg. 

A Tk.Blinkenlights felhasználói felületen a Sync inmediately 
(Azonnali összehangolás) gombra kattintva utasíthatjuk, 
hogy rögtön végezze el az összehangolást. 

A Curses.Blinkenlights felülettel dolgozva ugyanezt úgy 
érhetjük el, hogy rákattintunk a hozzáférés neve melletti 
számra. Mindkét felület megjeleníti a folyamatban levő te- 
vékenységek naplóját. lovábbá egy elbűvölő, élénk fényű 
állapotkijelzőt is bekapcsolhatunk, hogy ne unatkozzunk, 
miközben az összehangolás eseményeit követjük. 

A TITY.ITYUI illesztőfelület Curses támogatás nélkül is fut 
- nem használ sem színes, sem parancssoros ellenőrzést. 
Jelszóbevitelt tud olvasni, egyéb beavatkozási lehetőséget 
viszont nem nyújt. 

A Noninteractive. Basic felhasználói felület soha nem fogad 
bemenő adatokat a felhasználótól, viszont állapotüzenete- 
ket képes kijelezni. Ha a távoli kiszolgálóra történő belépés- 
hez jelszó szükséges, a beállításfájl távoli tárolási szakaszá- 
hoz a következő sort adjuk hozzá: 

remotepass - mypassword 


Végül pedig a Noninteractive.Ouiet egy lépéssel tovább- 
megy és nem ad ki állapotüzeneteket. Egyes felhasználók 
az OfflinelMAP-ot előszeretettel futtatják önműködő indí- 
tással (cron), erre a Noninteractíve. Ouiet kiválóan alkalmas. 
Kétféleképpen határozhatjuk meg, melyik felhasználói fe- 
lület kerüljön alkalmazásra. Az első lehetőség, hogy az 
OfflinelMAP parancssorában a -u kapcsolót használjuk. 
Kiadhatjuk például az offlineimap -u 
Curses.Blinkenlights utasítást. A másik lehetőség, hogy 
az általános szakaszhoz hozzáadunk egy Ui sort: 


ui - Tk.Blinkenlights, Curses.Blinkenlights, 


TTY.TTYUI 


Ilyen beállítás esetén az OfflinelMAP először 

a Ik.Blinkenlights felülettel próbálkozik. Ha a gépünkön le- 
vő Python nem támogatja a Ik-t, vagy pedig nem X-et hasz- 
nálunk, akkor a Curses.Blinkenlights felülettel próbálkozik. 
Ha ez sem vezet eredményre, megkísérli a TTY.TTYUI felü- 
letet használni. Ha egyik sem működik, az OfflinelMAáP hi- 
baüzenettel megszakítja a próbálkozásokat. 


Alkönyvtárak kijelölése 
Alapértelmezés szerint az OfflinelMAP lekérdezi a távoli 
IMAF-kiszolgálót, mely alkönyvtárak érhetők el számunkra, 
és ezek mindegyikét összehangolja. A távoli rész tárolási sza- 
kaszához hozzáadható a folderfi I ter lehetőség, ez behatá- 
rolja az áthozott adatokat. A folderfilter rendkívül nagy 
teljesítőképességű. Az eddig bemutatott lehetőségekkel ellen- 
tétben a folderfi Iter valóban azt várja, hogy Python-függ- 
vénynek adjuk át. A függvény egy változót vesz át és igaz ér- 
tékkel tér vissza, ha az adott alkönyvtárat is kezelni kell. 
A Python egy lambda nevű szolgáltatást is kínál, amellyel 
menet közben függvényeket tudunk létrehozni. Így össze- 
tett műveleteket is szerkeszthetünk. Lássunk néhány pél- 
dát! Kijelölhetjük azokat az alkönyvtárakat, amelyeket 
össze szeretnénk hangolni. A Pythont használhatjuk műve- 
letekbe ágyazva is, hogy ellenőrizzük, szerepel-e az adott 
postafiók a listában: 
folderfilter - lambda foldername: foldername in 
[ INBOX , "Sent Mail", 

 Received ] 


Ez a kód csak a három megnevezett alkönyvtárat hangolja 
össze. Figyeljünk arra, hogy a második és harmadik sor bel- 
jebb kezdődik -— a behúzottan írt sorokat az elemző ugyan- 
azon utasítás részeinek tekinti. 

Kizárás céljából is kijelölhetünk alkönyvtárakat: 


folderfilter - lambda foldername: foldername not in 
L spam , Junk 6] 


Ebben a példában a Spam és Junk kivételével minden al- 
könyvtár össze lesz hangolva. 
Hagyományos kifejezéseket is használhatunk: 


folderfilter - lambda foldername: 
not re.search( (ATrash$IDel) , foldername) 


Ez a kódrészlet kizárja a Irash nevű, valamint az összes 
olyan alkönyvtárat, amely tartalmazza a , Del" szöveget. 


Alkönyvtárak nevének módosítása 

Előfordulhat, hogy szeretnénk módosítani az alkönyvtárak 
nevét, mielőtt mentenénk őket. Az OfflinelMAP e művelet 
elvégzésére a nametrans nevű lehetőséget biztosítja, amely 

a távoli tárolási szakaszban is meg van adva. Egyes IMAP- 
kiszolgálók, mint például a Courier, minden alkönyvtár elejé- 
re beírnak egy ,INBOX." szöveget, ami bizony bosszantó is 
lehet. Ettől szabadulhatunk meg a nametrans lehetőséggel: 
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nametrans - lambda foldername: 
re.sub( AINBOXN. , " , foldername) 


A folderfilter-hez hasonlóan a nametrans is Python- 
kifejezést fogad. Ez a kifejezés változóként alkönyvtárnevet 
vesz át, és az új és javított alkönyvtárnevet fogja visszaadni. 
Ebben a példában minden INBOX.-tal kezdődő nevű al- 
könyvtár nevéből törlődik a kezdő ,INBOX." karakterlánc. 
Fontos, hogy ne csak a név elején levő , INBOX" törlődjék, 
hiszen INBOX alkönyvtár is létezik, s így egy üres nevű al- 
könyvtár maradna ránk, ami bizony hálátlan dolog lenne. 
A nametrans műveleteinkkel is bánjunk körültekintően. 
Ügyeljünk rá, hogy a nametrans minden egyes alkönyvtár 
esetében különböző értéket adjon vissza. Ha két különböző 
alkönyvtár számára azonos értéket ad, nemkívánatos ese- 
mények is bekövetkezhetnek. 

A nametrans ugyanis nem változtatja meg a folderfilter-t, 
vagyis folderfilter parancsaink még azelőtt hajtanak 
végre műveleteket az alkönyvtárakon, mielőtt a nametrans 
működésbe lépne. 


Két IMAP-kiszolgáló összehangolása 

Egyes levelezőprogramok nem támogatják eléggé a Maildir 
levéltárolási formát. Ezek számára az OfflinelMAáP új lehe- 
tőséget vezetett be, azaz két IMAP-kiszolgálót közvetlenül 
is össze lehessen hangolni. Az ötlet a következő: a helyi gé- 
peinkre IMAP-kiszolgálót telepítünk. Levelezőprogramunk, 
ami már rendelkezhet lassú IMAP-támogatással, gyorsan 
eléri a saját gépünkön levő IMAP-kiszolgálót. Az olvasó al- 
kalmazásnak nem kell tudnia, hogy az OfflinelMAP az al- 
könyvtárakba rakosgatja a leveleket. Ennek megvalósításá- 
hoz néhány egyszerű módosítást kell végrehajtanunk helyi 
tárolási szakaszunkban. Először is változtassuk meg a tí- 
pust Mai Idi r-ről IMAP-ra. Ezután töröljük a localfolders 
és egyéb Mai Idir adatokat, és helyettük válasszuk ki 

a remotehost és remoteuser IMAP-beállításokat. Végül pe- 
dig töröljük ki a —/.offlineimap könyvtárunkat, hogy a régi 
állapotadatok biztosan ne bújhassanak meg rossz helyen. 
Bizonyos lehetőségek még mindig csak a távoli szakaszban 
támogatottak - két példa a nametrans és a folderfilter —, 
de magára a kapcsolatra vonatkozó lehetőségek (options) 
mindkét helyen támogatottak. Helyi IMAP-kiszolgálónk va- 
lójában a távoli gépen is lehet. 


Összegzés 

Az OfflineIMAP hatékony levelezőalkalmazás. Írásomban 
az OfflinelMAP alapjait mutattam be. lovábbi ismereteket 
az OfflinelMAP honlapról szerezhetünk és a példaként 
szolgáló beállításfájlok alapján. Python programozók talál- 
hatnak itt néhány , szép" buktatót is, amelyek Python- 
kódok fejlesztésekor jelentkezhetnek. 
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Alkalmazásszíintű proxyzás a Zorp segítségével 42. rész) 


A Zorp proxykiszolgáló a rendszermag Netfilterével együttműködve 
alkalmazásszíntű, az ügyfelek számára átlátszó proxyzást végez. 


lőző írásomban ódákat zengtem az alkalmazásszintű 
proxytűzfalakról, valamint Scheidler Balázs kereskedel- 
mi és ingyenes változatban egyaránt elérhető Zorp 
tűzfalcsomagját mutattam be. Ez alkalommal ott folytatom, 
ahol abbahagytam, vagyis áttekintem a Zorpnak azokat az 
alapszintű beállításait, amelyekre egy belső hálózat — demili- 
tarizált zóna (DMZ) - külső hálózat környezetben szükség le- 
het. Csak néhány szolgáltatás beállításáról lesz szó, de bízom 
abban, hogy ezek alapján a leendő Zorp-felhasználók meg 
tudják kezdeni saját intelligens tűzfalrendszerük kiépítését. 
Idézzük fel néhány szóban az alkalmazásszintű proxyk fel- 
adatát. A proxyk nem pusztán továbbadják, sokkal inkább 
közvetítik a rajtuk keresztül haladó forgalmat. Például, ha 
a belső hálózat valamelyik felhasználója HIIP-kapcsolatot 
kezdeményez egy a proxytűzfal túloldalán lévő kiszolgáló- 
val, a tűzfal elfogja és megtöri a kapcsolatot; így kiszolgáló 
(az ügyfél felől nézve) és ügyfél (a célkiszolgáló oldaláról 
szemlélve) szerepet egyaránt játszik. 

A Zorp átlátszó proxykat használ, a Zorp tűzfal mögött dol- 
gozó felhasználóknak tehát nem kell tudniuk róla, hogy 
tűzfal védi őket — olyan módon érhetik el a külső címeket 
és állomásneveket, hogy saját alkalmazásaikban nem kell 

a proxyval való kapcsolattartáshoz szükséges beállításokat 
megadniuk. Ezt fontos kiemelni, mert lényeges ellenérv- 
ként szolgál, ha azzal az idejétmúlt nézettel találkozunk, 
hogy a proxyk szükségszerűen sokkal bonyolultabbak, mint 
a másfajta tűzfalak. A Zorp használatakor a bonyolultság 

a háttérrendszernél jelentkezik, a felhasználók boldogságát 
így semmi sem árnyékolja be. 

Ugyanakkor a Zorp használata a rendszergazda számára sem 
feltétlenül jelenti a kínok kínját. Ha engem kérdeznének, azt 
mondanám, a beállítása bonyolultabb, mint az iptables be- 
üzemelése, de könnyebb, mint a sendmail.cf megírása. Ne is 
várjunk tovább, húzzuk fel saját Zorp tűzfalunkat! 


Előfeltételek 

A továbbiakban feltételezem, hogy előző írásom alapján si- 
keresen foltozott 2.4-es rendszermaggal rendelkezel, 
iptables-példányod pedig támogatja a Tproxy modult 
(lásd 8 http:/www.balabit.hu/products/oss/tproxy). Felte- 
szem azt is, hogy lefordítottad és telepítetted a libzorpl!1, 
a zorp és a zorp-modules csomagokat - forráskód vagy 
deb-csomag formájában ezek a 3 http://www.balabit.com/ 
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products/zorp gpl címről érhetők el. Példáim ugyan a Zorp 
GPL 2.0-s változata alapján készültek, de Zorp Pro 2.0-s 
alatt is érvényesek. A Zorp Pro rendelkezik néhány olyan 
proxymodullal, amelyeket a Zorp GPL nem tartalmaz, de 

a közös modulok azonosan működnek. 


A környezet 

A Zorp tűzfalanként háromnál jóval több csatoló támogatá- 
sára is képes, ám a leggyakrabban az 1. ábrán láthatóhoz ha- 
sonló, háromlaki rendszerekkel találkozhatunk. A további- 
akban ilyen hálózat meglétét feltételezem. 

Amint az 1. ábráról is kitűnik, összesen három adatáramlási 
irányt különböztetünk meg: HIITP-forgalom az internet és 
a DMZ-ben lévő webkiszolgáló között; HITP-forgalom 

a belső hálózat és az internet között; HTIP és SSH-forga- 
lom a belső hálózat és a DMZ között. Nem térek ki olyan, 
még az egyszerűbb hálózatokban is általánosan használt 
szolgáltatásokra, mint az IMAP az NNIP vagy az FIR Ha 
megérted, hogyan tudod beállítani a Zorpot a fenti alap- 
szolgáltatások támogatására, akkor a többivel is boldogulni 
fogsz. A DNS és az SMIP viszont szóba fog kerülni, függet- 
lenül attól, hogy az 1. ábráról lemaradtak. 


Dummy csatoló megadása 

Az első dolog, amivel foglalkoznunk kell, nem annyira 

a Zorp, inkább a Iproxy rendszermagmodul működésével 
függ össze. Átlátszó proxyzásnál a Tproxynak szüksége van 
egy dumny (néma, ál-) hálózati csatolóra, amelyhez az 
adatfolyamok kettéválasztásakor kötődni tud. Ennek a csa- 
tolónak olyan IP-címet kell adni, amely az interneten nem 
irányítható, és a tűzfalhoz csatlakozó hálózatok egyikébe 
sem tartozik. 

A 2.4-es rendszermagok alapértelmezett fordítás után 

is támogatják a dummy hálózati csatolók használatát. 
Valószínűleg neked is van ilyened, hacsak nem a dummy 
illesztőprogram támogatása nélkül fordítottad a rend- 
szermagot. Ha így tettél, most új, dummy-támogatás- 

sal rendelkező rendszermagra lesz szükséged. A Tproxy 
működéséhez mindössze annyit kell tenned, hogy 
megadsz egy dummy0O csatolót, és nem irányítható, 
használaton kívüli címet rendelsz hozzá. Debian alatt 

a következő sorokat kell hozzáadnod a /etc/networking 
/interfaces fájlhoz: 


Tűzfal 


HTTP ; Webkiszolgáló 
(TCP 80) // 192.168.1.240 


SSH (ICP 22) 


1. ábra Példahálózat 


HTIP "08 
(ICP 80) 


Tűzfal 


HITP 
(TCP 80) 7 


2. ábra HTIP-kapcsolat, amely a kék számára kimenő, 
a piros számára bejövő 


auto dummyO 

iface dummyO inet static 
address 1.2.3.4 
netmask 255.255.255.255 


Más terjesztések alatt ettől eltérhet a hálózati beállítások ke- 
zelése. A Red Hat- és a SuSE-terjesztések például ifcfg fájlo- 
kat helyeznek a /etc/sysconfig/network könyvtárba. Remé- 
lem, azért könnyen meg tudod fejteni a jelentésüket. lalán 
feltűnt, hogy az imént 32 bites alhálózati maszkot adtam 
meg. Miért? Ismétlem, a dumny csatoló címének egyik há- 
lózatba sem kell tartoznia. 


Beállítások: iptables 

Jogos a kérdés, most a Zorp vagy az iptables a téma? 

A helyzet az, hogy a Zorp nem az iptables helyett, hanem 
vele együttműködve végzi feladatát. Maga a Iproxy is egy 
Netfilter-folt. A Tproxyt az iptables paranccsal tudjuk be- 
állítani, ahogy a Netfilter egyéb részeit is. (A Netfilter 
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a Linux 2.4-es tűzfalkódjának neve, az iptables pedig 

az a parancs, amellyel a rá vonatkozó beállításokat meg- 
adhatjuk.) 

Emellett bizonyos szolgáltatásokat, különösen a DNS-t és 

az SMIFP-t ajánlott öntartalmazó proxyként (self-contained 
proxies) futtatni a tűzfalon. Ha így teszel, akkor az iptables 
segítségével közvetlenül be kell állítanod a tűzfalat e kap- 
csolatok elfogadására. Például a BIND v9 támogatja a látha- 
tár-megosztásos (split-horizon) DNS-szolgáltatást, amely 

a külső és a belső ügyfeleket más-más zónafájlokból szolgál- 
ja ki. Hasonlóan a Postfixet is könnyen be lehet állítani oly 
módon, hogy közvetítőként szolgáljon a belső állomások 
számára, de kizárólag helyi szállítást végezzen, ha külső ál- 
lomásokkal kerül kapcsolatba. Ilyen proxyjellegű szolgálta- 
tásokat sokszor érdemes a tűzfalon futtatni, feltéve, hogy 
beállításuk során rendkívüli gondossággal járunk el. 

Ha nem vagy jártas a Netfilter/iptables kezelésében, akkor 
az alábbiakat nem nagyon fogod érteni, és sajnos helyhiány 
miatt nekem sincs módom arra, hogy részletesebb magyará- 
zatokkal szolgáljak. Sajnálom, de a Zorp nem kezdőknek 
való eszköz. Dióhéjban csak annyit, hogy az iptables segít- 
ségével minden csomagot egyszerű ellenőrzésnek vetünk 
alá, amely során megpróbáljuk kiszűrni a hamisított IP- 
címeket. Ezután elfogjuk az átlátszó proxyzásra kiszemelt 
csomagokat, majd a normál FORWARD lánc helyett egyedi lán- 
cok segítségével dolgozzuk fel őket. lovábbítani lényegében 
semmit nem fogunk. Végül gondoskodunk néhány, magá- 
nak a tűzfalnak küldött csomag célba juttatásáról. 

A Zorp Próhoz egy iptables-utils nevű parancsfájlgyűjte- 
mény is tartozik, ezek segítségével lényegesen leegyszerű- 
södik az iptables Zorp-vonatkozású kezelése. Az iptables- 
utils ingyenes kiadása a Zorp GPL 2.0-s változathoz 

a 5 http:/www.balabit.com/downloads/zorp/zorp-os/pool/ 
jiptables-utils címről tölthető le. Mindenkinek javaslom, 
hogy próbálkozzon meg az iptables-utils használatával, 
segítségével ugyanis sokkal könnyebb kipróbálni egy 
iptables-beállítást, mielőtt érvénybe léptetnénk. 
Írásmódját helyhiány miatt nem ismertethetem, ezért az 
alábbi példa egy hagyományos iptables indítóparancsfájl 
lesz. lekintsük át a parancsfájl legfontosabb részeit! Elöl 
találhatók a különleges tproxy tábla szabályai, ezeket 

a Tproxy modul adja hozzá a Netfilterhez (1. kódrészlet). 

Itt saját hálózataink mindegyikéhez egy-egy egyedi proxy- 
láncot adunk meg: PRkék a belső hálózat felől indított, 
proxyzott kapcsolatok számára; PR1li la a DMZ felől indított 
és proxyzott kapcsolatokhoz (ebben az esetben nincs ilyen); 
PRpi ros az internetről indított, proxyzott kapcsolatok 
számára. 

Az 1. kódrészletben több érdekes dolgot is találunk. Először is 
a tproxy tábla saját PREROUTING és OUTPUT kimeneti lánco- 
kat tartalmaz. Zorp alatt a tproxy/PREROUTING lánccal to- 
vábbítjuk a csomagokat a megfelelő egyedi proxylánc felé 
(PRkék), annak alapján, hogy az egyes csomagok mely csa- 
tolón érkeznek be. Mint minden egyedi iptables láncnál, 
ha egy csomag úgy halad keresztül ezek valamelyikén, 
hogy egyik szabállyal sem mutat egyezést, akkor ahhoz 

a sorhoz kerül vissza, amely a csomagot az egyedi láncba 
küldő szabályt közvetlenül követi. Ez az oka annak, hogy 
az egyedi láncok nem tartalmaznak alapértelmezett célokat. 
A PRkék láncban két szabály található, mind a kettő a belső 
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1. kódrészlet TIproxy-szabályok 


iptables -t tproxy -P PREROUTING ACCEPT 

iptables -t tproxy -A PREROUTING -i ethi -j 

ss PRkék 

iptables -t tproxy -A PREROUTING -i eth2 -j 

sspPRlila 

iptables -t tproxy -A PREROUTING -i eth0 -]j 

53 PRpiros 

iptables -t tproxy -P OUTPUT ACCEPT 

iptables -t tproxy -N PRkék 

iptables -t tproxy -A PRkék -p tcp --dport 8ON 
-j TPROXY --on-port 50080 

iptables -t tproxy -A PRkék -p tcp --dport 224 


! -d tuzfal.pelda.net -j TPROXY --on-port 50022 
iptables -t tproxy -N PRlila 


iptables -t tproxy -N PRpiros 
iptables -t tproxy -A PRpiros -p tcp --dport 
SZO N 

-j TPROXY --on-port 50080 


hálózat felől kiindulni engedélyezett forgalomtípushoz egy- 
egy. Minden kimenő HITP-forgalom proxyzásra kerül, va- 
gyis átadásra egy az 50080-as kapun csücsülő 
proxyfolyamat felé. Az SSH-szabály annyiban más, hogy 

itt a Netfilternek csak addig kell proxyznia a kimenő SSH- 
forgalmat, amíg az nem maga a tűzfal felé irányul. Ugyan 
az 1. ábrán ezt a forgalomtípust nem tüntettem fel 
(KékoSSHO I űzftal), azonban a tűzfal felügyeletéhez szük- 
ség van rá. Ehhez az adatforgalomhoz a normál szűrőtábla 
INPUT láncában is szükséges egy szabály. A példahálózatban 
a DMZ-be helyezett webkiszolgáló nem kezdeményezhet 
semmilyen kapcsolatot, ezért a PR1i la lánc üres maradt. 
Lépjünk tovább a normál szűrőtáblára. Ez az a Netfilter 
tábla, amit valószínűleg sokan ismernek, az iptables ezt 
tekinti alapértelmezettként, ha a -t kapcsolót elhagyjuk. 

A 2. kódrészletben a példatűzfal szűrőtáblájának INPUT szabá- 
lyai láthatók. 

Az első néhány sor segítségével — egyedi láncok felhaszná- 
lásával — megpróbáljuk kiszűrni a hamisított IP-címeket. Ha 
egy csomag túljut ezen az ellenőrzésen, akkor lejjebb lép az 
INPUT láncban. A Tproxy modul által létrehozott csomago- 
kat elfogadjuk, nemkülönben a meglévő és engedélyezett 
kapcsolatokhoz tartozókat és a hurokcsomagokat (loopback 
packets; 4-6. sor). Következőként, ahogy a tproxy tábla 
PREROUTING láncával is, a bejövő csatolójuk alapján a cso- 
magokat egyedi láncokhoz irányítjuk. Ezeket az egyedi lán- 
cokat helyi célcímmel ellátott csomagokhoz készítettük, 
nem proxyozott csomagokhoz, ezért Lokék és hasonló ne- 
vekkel láttam el őket. Ezután lássuk a szűrőtábla egyedi 
láncait (3. kódrészlet). 

Az egyedi láncok közül az első három a legfontosabb: 
HEkék, HEli la és HEpi ros, ezek adják meg a Netfilternek, 


hogyan kezelje a tűzfalnak küldött csomagokat, attól függő- 
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Szaktekintély [NNNNNNNINININIIXKKK CL SSZZSZSZSSZS 


2. kódrészlet A szűrőtábla INPUT lánca 


iptables -P INPUT DROP 

iptables -A INPUT -j zaj 

iptables -A INPUT -j hamis 

iptables -A INPUT -m tproxy -j ACCEPT 
iptables -A INPUT -m state NM 


--state ESTABLISHED, RELATED -j ACCEPT 


iptables -A INPUT -i lo -j ACCEPT 

iptables -A INPUT -i ethi1 -j Lokék 

iptables -A INPUT -i eth0 -j Lopiros 
iptables -A INPUT -i eth2 -j Lolila 

iptables -A INPUT -j LOG --1]og-prefix "INPUT 
s DROP: " 

iptables -A INPUT -j DROP 


en, hogy melyik csatolón keresztül érkeztek be. A HEkék 
lánccal elfogadjuk a DNS-lekérdezéseket, az SSH- és az 
SMIP-kapcsolatokat. A HET i la csak a DNS-lekérdezéseket 
engedélyezi. Végül a HEpi ros lánccal az internetszolgáltató 
DNS-kiszolgálójának (upstream.dns.server) válaszait és az 
SMIP-kapcsolatokat engedjük tovább. Az egyedi láncok kö- 
zül az utolsó három a legegyszerűbb: a zaj a linuxos tűzfa- 
lak naplóit hagyományosan zagyvasággá változtató 
NETBIOS-csomagokat tartja távol; a hamis az egyértelműen 
hamisított, vagyis érvénytelen forrás-IP-címmel érkező cso- 
magokat szűri ki; a hamis eldob pedig a hamis által elfogott 
csomagokat naplózza és dobja el. 

A 4. kódrészlet iptables példaparancsfájlunk maradékát tar- 
talmazza, egy lényegében üres FORWARD láncot egy alapér- 
telmezett DROP házirenddel, valamint egy üres OUTPUT lán- 
cot alapértelmezett ACCEPT lánccal. Ismétlem, ez egy 
proxytűzfal, így semmit sem fog továbbítani. A tűzfalról 
származó csomagokra vonatkozó alapértelmezett ACCEPT 
házirend miatt lehet, hogy gombóc marad a torkodban, de 
semmi gond, Zorp alapú tűzfal esetében az ilyesmi szüksé- 
ges és biztonságos is. 


Zorp-példányainak beállítása 

Végre elérkeztünk a Zorp beállításait megadó fájlokhoz. 
Ezeket a /etc/zorp könyvtárban találjuk; mindjárt vessük is 
rá magunkat az instances.conf fájlra, amely megadja a Zorp- 
példányokat, illetve szabályozza a működésüket. Ökölsza- 
bályként elfogadható, hogy hálózati zónánként egy pél- 
dány szükséges, ezért példakörnyezetünkben, mint már 
nyilván kitaláltad, a piros, a kék és a lila zónához egyaránt 
egy-egy példány tartozik. Az 5. kódrészlet szemlélteti, ho- 
gyan kell kinéznie egy instances.conf fájlnak. 

Minden sorban az első mező a példány neve. A nevet sza- 
badon választhatjuk meg, de ügyeljünk arra, hogy a Zorp 
policy.py beállításfájljában hibátlanul kell hivatkoznunk rá. 
Ha már itt tartunk, amennyiben úgy gondoljuk, az egyes 
példányokhoz külön beállítófájlokat is megadhatunk, de 
egyetlen fájlban felsorolhatjuk több zóna beállításait is. 
leljesen mindegy, melyik megoldást választjuk, az 
instances. conf -p kapcsolója adja meg a Zorpnak, hogy 
melyik példányhoz melyik fájl társul. 

A -v kapcsolóval a naplóüzenetek részletességét szabályoz- 


3. kódrészlet Egyedi láncok a szűrőtáblában 


iptables -N 
iptables -A 
sz ACCEPT 


iptables -A 
iptables -A 
SS ACCEBT 
iptables -A 
s DROP: " 
iptables -A 


iptables -N 
iptables -A 
iptables -A 


Lokék 
Lokék ép tép sdbort 22/--syn j 


Lokék -p udp --dport 53 -j ACCEPT 
Lokék -p tcp --dport 25 --syn -j 


Lokék -j LOG --1]og-prefix "Lokék 
Lokék -j DROP 
Lolila 


Lolila -p udp --dport 53 -j ACCEPT 
Lolila -j LOG N 


--]og-prefix "Lolila DROP: " 


iptables -A 


iptables -N 
iptables -A 


Lolila -j DROP 


LOpiros 
LOpiros -p udp -s 


s upstream.dns.server N 
-sport 53 -j ACCEPT 


iptables -A 
"3 ACCEPT 
iptables -A 
S DROP: " 
iptables -A 


iptables -N 
iptables -A 
iptables -A 


iptables -N 
iptables -A 
iptables -A 


Lopiros -p tcp --dport 25 --syn -j 


LOpiros -j LOG --1]og-prefix "LOpiros 


LOpiros -j DROP 


zaj 
zaj -p udp --dport 137:139 -j DROP 
zaj -j RETURN 


hamis 
hamis -i lo -j RETURN 
hamis! -i lo -s 127.0.0.0/8 -j 


3 hamis eldob 


iptables -A hamis -i ethi ! -s 10.0.1.0/24 NM 
-J] hamis eldob 

iptables -A hamis! -i eth1 -s 10.0.1.0/24A NN 
-J] hamis eldob 

iptables -A hamis -i eth2 ! 
-J7 hamis eldob 

iptables -A hamis! -i eth2 -s 192.168.1.0/24 NM 
-Jj hamis eldob 

iptables -A hamis -j RETURN 


-s 192.168.1.0/24 NM 





4. kódrészlet A szűrőtábla FORVVARD 
és OUTPUT láncai 


iptables -P FORWARD DROP 

iptables -A FORWARD -j LOG N 
--]og-prefix "FORWARD DROP: " 

iptables -A FORWARD -j DROP 


iptables -P OUTPUT ACCEPT 


5. kódrészlet Az instances.conf 


kék -v3 -p /etc/zorp/policy.py NM 
--autobind-ip 1.2.3.4 

lila -v3 -p /etc/zorp/policy.py NM 
--autobind-ip 1.2.3.4 

piros -v3 -p /etc/zorp/policy.py NM 
--autobind-ip 1.2.3.4 
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6. kódrészlet A policy.py; 
1. rész (átfogó érvényű beállítások) 


from Zorp.Core import " 
from Zorp.Plug import " 
from Zorp.Http import " 


InetZone("kékzóna", "10.0.1.0/24", 


outbound services-[/kék http", "kék ssh"], 


Inetzone("lilazóna", "192.168.1.0/24", 
inbound services-["kék http", "kék ssh", 
"piros http"]) 


InetZone("piroszóna", "0.0.0.0/0", 
outbound services-[/piros http" ], 


inbound services-[/7"]) 


InetZzone("helyizóna", "127.0.0.0/8", 
inbound services-["""]) 


ft átfogó érvényű szakasz vége 


iptables -N hamis eldob 

iptables -A hamis eldob -j LOG N 
--]og-prefix "Hamisított csomag: 

iptables -A hamis eldob -j DROP 


nézve lehet azonos is, sőt lehetőleg ezt a megoldást vá- 
lasszuk. Az itt megadott címnek értelemszerűen egyeznie 
kell a korábban beállítottal. (Lásd a , Dummy csatoló meg- 
adása" című részt.) 


A Zorp alkalmazásproxyk beállítása: policy.py 

Az iptables parancsfájl határozza meg, hogy a csomagok 
hogyan jutnak el a proxykhoz, a /etc/zorp/instances.conf pe- 
dig a Zorp indulását szabályozza. Nyilván a Zorp proxy- 
jainak viselkedését is vezérelni kell valahogyan, erre a célra 
a /etc/zorp/policy.py fájl szolgál, illetve az a fájl vagy azok 

a fájlok, amelyet vagy amelyeket az instances.conf fájlban 


hatjuk: a 3-as a közepes szint, az 5-ös pedig hibakeresésre 
használható. Ezzel a kapcsolóval csak a Zorp által létreho- 
zott naplóüzenetek tartalmát szabályozhatjuk, a Netfilter/ 
iptables naplózására nincs hatással. Végül minden sor egy 
--autobind-ip beállítással zárul, ez határozza meg, hogy 
a kapcsolatok proxyzásakor a Zorpnak melyik dummy IP- 
hez kell kötnie a Tproxyt. Ez az ÍP-cím az összes példányra 
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7. kódrészlet A policy.py; 
2. rész (példányok megadása) 


def kékO : 
Service("kék http", HttpProxy, 
router-TransparentRouter() ) 
Service("kék ssh", PlugProxy, 
router-TransparentRouter() ) 


Listener(SockAddrInet( 10.0.1.254 , 50080), 
"kék http") 
Listener(SockAddrInet( 10.0.1.254 , 50022), 
"kék ssh") 
def lilaO: 
pass 


def pirosO: 

Service("piros http", HttpProxy, 
router-Di rectedRouter(SockaAddrInet( 192.168.1.24 
sz 80 ő 
forge addr-TRUE)) 

Listener(SockaáAddrInet( 169.254.1.254 , 
ss 50080) , 

"piros http") 


megneveztünk. A policy.py a megszokott név, de szabadon 
eltérhetünk tőle. A házirendífájl két részból áll: az első rész- 
ben az átfogó érvényű beállítások találhatók, itt a zónák 
megadása a hálózati címek és a megengedett szolgáltatások 
szerint történik. A második rész a szolgáltatás-példány- 
megadásokat tartalmazza, ebben az instances.conf fájlban 
felsorolt példányok megadása a szolgáltatások kiinduló he- 
lye alapján történik, továbbá itt írhatjuk elő a szolgáltatások 
alkalmazásproxykhoz való hozzárendelését is. 

A 6. kódrészlet teljes egészében tartalmazza policy.py példa- 
fájlunk átfogó érvényű szakaszát. Néhány import pa- 
ranccsal kezdődik, ekkor végezzük el a szükséges Python- 
függvények beemelését. A következő rész a zónamegadáso- 
kat tartalmazza. Ha az instances.conf fájlban zónánként egy 
Zorp-példányt adunk meg, akkor az itt használt zónanevek 
lehetnek hasonlók a példánynevekhez, vagy akár meg is 
egyezhetnek velük. A 6. kódrészletben én eltérő neveket 
választottam, ezzel is szemléltetni próbáltam a zónanevek 
és a példánynevek egymástól való függetlenségét. 

Minden zónamegadásban az 1. ábrán szereplő hálózatcíi- 
mek valamelyikét és az engedélyezett szolgáltatások meg- 
adását találjuk. A szolgáltatásneveket szabadon választhat- 
juk meg, használatukra a következő részben, a szolgáltatás- 
példányok megadásakor kerül sor. Az utasításokkal kapcso- 
latban fontos kiemelni, hogy a bejövő és a kimenő irányo- 
kat mindig a zónához vagy a hálózathoz, és nem a tűzfal- 
hoz viszonyítva kell érteni. 

A 2. ábrán követhetjük, hogy a belső hálózat-internet irá- 
nyú HIIP-kapcsolatok proxyzott kapcsolatként viselked- 
nek. Az ábra alapján egyértelmű, hogy a teljes kapcsolat lét- 
rejöttéhez egyrészt szükség lesz egy kimenő kapcsolatra 

a belső zónából (kék), valamint egy bejövő kapcsolatra az 
internetzónába (piros). Ennek megvalósulása rendre követ- 
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hető a 6. kódrészlet kékzóna és a piroszóna szakaszában. 
Fontos, hogy mindkét olyan zóna megadásakor, amit vala- 
milyen adatfolyam érint, ugyanazt a szolgáltatásnevet hasz- 
náljuk (a 2. ábra és a 6. kódrészlet esetében ez a kék http). 
A 6. kódrészlet kapcsán még annyit mondanék el, hogy a " 
(csillag) helyettesítő karakter minden megadott szolgáltatást 
helyettesít. Ez csak első ránézésre jelent sok mindent, a " 
ugyanis csak azokat a szolgáltatásokat helyettesíti, amelyek 

a policy.py fájl szolgáltatás-példány-párosításaiban szerepel- 
nek, és nem az összes lehetséges szolgáltatást. Ne feledjük, 
hogy a Zorp csak a Netfilter és a Tproxy által hozzá eljuttatott 
csomagokat dolgozza fel. Ha egy zónában sem a bejövő, sem 
a kimenő kapcsolatokat nem akarjuk engedélyezni, akkor az 
inbound services vagy az outbound services kulcsszót el- 
hagyhatjuk, illetve üres szögletes zárójelet írhatunk mögé. 

A 7. kódrészlet a policy.py fájl szolgáltatás-példány-megadá- 
sait tartalmazza. Minden megadás első sorának egy az 
instances.conf fájlban szereplő példánynévre kell hivatkoz- 
nia, a további sorokat pedig be kell húzni, a feldolgozás 
ugyanis a behúzásokra nézve elég finnyás Pythonnal törté- 
nik. A megadás nem lehet üres. Ha adott példánytól nem 
indul ki szolgáltatás, akkor a pass kulcsszót kell használni. 
Erre a 7. kódrészlet lila) példányánál láthatunk példát. 
Egyéb esetben a megadásnak egy vagy több Service sorból 
kell állnia, ezek egy vagy több zónamegadásban hivatkozott 
szolgáltatásnevet és egy Zorp proxymodult tartalmaznak. 
Utóbbi beépített, az átfogó érvényű befoglaló utasításokkal 
beemelt vagy egyedi osztályban megadott proxy egyaránt 
lehet. A Service sorok utolsó mezője a router, ez adja 
meg, hogy a proxyzott csomagokat hova kell küldeni. 

A 7. kódrészletben például a piros http szolgáltatásnál 

a forge addr-TRUE paranccsal változatlan formában adjuk 
át az internetről érkező webes ügyfelek forrás-IP-címét 

a webkiszolgálónknak. Ha ezt a parancsot elhagynánk, 
akkor a DMZ-be befutó webes forgalom forrása látszólag 

a tűzfal lenne. 

Ugyan a 7. kódrészletben csak a HttpProxy és a PlugProxy 
(általános célú UDP- és TCP-proxy, amely az alkalmazások 
adatait módosítás nélkül másolja) használatára látunk példát, 
a Zorp GPL FIP whois, SSL, telnet és finger proxyval is 
rendelkezik. Miként már utaltam rá, saját osztályokat is ké- 
szíthetünk, ha szeretnénk módosítani vagy bővíteni a meglé- 
vő proxykat. Könnyedén létrehozhatunk például URL- 
szűrést végző HIITP-proxyt, vagy a HIIPS-forgalom intelli- 
gens proxyzására képes, HIIP-proxyra ültetett SSL-proxyt. 
Sajnos ezek már magasabb szintekre tartozó témák, amelyek- 
kel itt nem foglalkozhatunk. Szerencsére a Zorp Python 
proxymoduljai bőségesen el vannak látva megjegyzésekkel. 
A 7. kódrészletben szereplő TransparentRouter egyszerűen 
proxyzza a csomagokat az ügyfél által megadott cél-IP-címre 
és -kapura. A piros példány piros http szolgáltatásánál 
azonnal láthatunk példát a Di rectedRouter használatára is, 
ennél kötelező érvényű cél-IP-címet és -kaput is elő kell írni. 
Egy szolgáltatás-példány-megadás minden Service sorá- 
hoz tartoznia kell egy Listener sornak. Ez a sor adja meg 

a Zorpnak, hogy melyik helyi (tűzfal) IP-címhez és kapuhoz 
kell a szolgáltatásnak kötődnie. Furcsának tűnhet, hogy 

a 7. kódrészlet Listener soraiban elég magas sorszámú ka- 
puk szerepelnek, 80 helyett 50080 és 22 helyett 50022. Ne 
feledkezzünk meg azonban arról, hogy mindegyik proxy 


a Netfilteren keresztül, a rendszermagtól kapja a csomago- 
kat, nem pedig közvetlenül az ügyfelektől. Az itt megadott 
kapuszámoknak tehát egyezniük kell a tproxy tábla 
Netfilter-szabályaiban meghatározottakkal (1. kódrészlet). 
Már említettem, hogy míg a HttpProxy egy teljes mérték- 
ben alkalmazástudatos, a helyes HIIP-működés érdeké- 
ben a vonatkozó RFC-ket mindenben követő proxy, illetve 
a PlugProxy egy általános célú proxy. A PlugProxy még így 
is jobb védelmet nyújt, mint a puszta csomagszűrés, ugyan- 
is még az önmagában, alkalmazástudatos működés nélkül 
végzett proxyzás is többre képes, mint a Nettfilter, hiszen 
utóbbival ellentétben meg tudja védeni rendszerünket az 
alacsony szintű támadásoktól. 


Összegzés 

lalán mondanom sem kell, rendkívül felszínesen tekintettem 
csak át a Zorp GPL szolgáltatásait. Messze ez a legbonyolul- 
tabb eszköz, mellyel ezeken az oldalakon valaha is foglalkoz- 
tam, de bízom benne, senki nem fogja elvesztegetettnek hin- 
ni azt az időt, amit a Zorp megismerésére fordított. 


Cinux dodrna! 2004. apmhs a t20. számi 


Mick Bauer (mickEovisi.com) 

Biztonsági szakember, a Linux Journal 
biztonsági témákkal foglalkozó szerkesztője, 
biztonsági tanácsadó a Minnesota állambeli 
Minneapolisban található Upstream Solutions 
LLC Inc.-nél. 
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A Zorp készítőinek (Balabit Kft.) magyar nyelvű honlapja 
2 http:/Avww.balabit.hu címen érhető el. 

A ZorpOS letöltési könyvtárának gyökerében található 
néhány olyan eszköz, amelyekkel a Zorp GPL használata 
jóval könnyebbé válik (többek közt az iptables-utils, 
TI proxy-képes Linux-rendszermag és iptables parancs). 
Ezek lényegében a Zorp Próval beszerezhető Deblan- 
terjesztés ingyenes részei, ez az oka annak, hogy 

a ZorpOS-ben minden Debian csomagok formájában 
szerepel. Ha nem Debiant használsz, akkor minden 
szükséges elemet megtalálsz a pool könyvtár alkönyvtá- 
raliban. Az egyes csomagok alkönyvtáraiban legfelül for- 
ráskódokat tartalmazó tar.gz fájlok találhatók. Ha 
Debilant használsz, akkor a 3 http://www.balabit.com/ 
downloads/zorpízorp címet apt-get forrásként hasz- 
nálhatod. 

A Zorp-felhasználók levelezőlistája rendkívül gyors és 
könnyű módja a segítségkérésnek, akár a Pro, akár 

a GPL Zorp-változattal akadna gondod. A listára az aláb- 
bi oldalon lehet feliratkozni, illetve archívuma Is innen 
érhető el. Megjegyezném, hogy a Balabit egy magyar 
vállalkozás, így mérnökei (valamint a leghozzáértőbb 
Zorp-használók egy része) közép-európai idő szerint 
dolgoznak: 

2 http://https://lists.balabit.hu/mailman/listinfo/zorp 
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Biztonságos levelezés LDAP és IMAP 


segítségével (2. rész) 


Ha sikerül egy IMAP-levélkiszolgálót egy LDAP-címtárral házasítanunk, akkor min- 
den egyszerűbbé és biztonságosabbá lesz, és a felhasználók Is könnyebben tud- 
nak levelezni. Mick ezúttal a rázósabb témákról szól, amelyeken keresztülrágva 
magunkat a cég elektronikus levélügyi szakértőjévé képezhetjük magunkat. 


z LDAP és a Cyrus IMAP-kiszolgáló együttes hasz- 
AA nálatáról szóló cikksorozat első részében telepítet- 

tük és beállítottuk a Cyrus IMAP-ot és a Cyrus 
SASL-t. Ez alkalommal felhasználókat adunk a Cyrus IMAP 
adatbázisához, majd olyan módon állítjuk be a Postfixet, 


hogy a Cyrus IMAP-kiszolgálónak továbbítsa a leveleket. 


A Cyrus IMAP leírása 

Mielőtt elmerülnénk a Cyrus IMAP beállításának és fel- 
ügyeletének részleteiben, egy megjegyzés a leírásokkal kap- 
csolatban. A Cyrus IMAP-hoz html-formátumú rendszer- 
gazdai útmutató jár. A SuSE-terjesztésekben a kézikönyv 

a /usr/share/doc/packages/cyrus-imapd/doc, Simon Matter 
Red Hat SRPM terjesztésében (lásd a cikksorozat első ré- 
szét) pedig a /usr/share/doc/cyrus-imapd-2.1.12 útvonalon 
érhető el. A megtévesztő Installation (telepítés) névvel el- 
látott hivatkozás egy olyan oldalra vezet, amely nemcsak 

a telepítéssel, de a beállítással és a felügyeleti teendőkkel 
kapcsolatos tudnivalókat is tartalmazza. A kézikönyv mel- 
lett számos súgóoldal is tartozik a Cyrus IMAP-hoz, a leg- 
fontosabbak az imapd.conf(5), az imapd(8) és a cyradm(1). 
A Cyrus IMAP elektronikus leírása mellett érdemes tanul- 
mányozni Dianna és Kevin Mullet , Managing IMAP" című 
könyvét is. Amennyire én tudom, ez az egyetlen kizárólag 
IMAP-pal foglalkozó könyv. A Cyrus IMAP kapcsán az 
LDAP használatára ugyan már nem tér ki, de rendkívül jól 
megírt könyv, amely tisztán és érthetően magyarázza el az 
IMAP-pal kapcsolatos fogalmakat és a Cyrus IMAP felügye- 
letét, továbbá az UW-IMAP-pal is foglalkozik. 


A cyradm használata 

A Cyrus IMAP-hoz tartozik egy Perl parancsfájl, a cyradm, 
ezzel lehet a legkényelmesebben létrehozni és kezelni 

a felhasználók postaládáit. A cyradm használatba vétele 
előtt jó néhány dologgal kell tisztában lennünk. Először is 

a cyradm-ot olyan fiókkal kell futtatni, amit elektronikus 
levelek olvasására nem használunk. Másként fogalmazva, 
elektronikus levelezésre soha ne használjunk felügyeleti 
IMAP-fiókot. A szokatlantól eltérő írási—olvasási engedélyek 
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miatt az ilyen fiókot levélolvasásra és -küldésre használva 
kedvezőtlenül befolyásolhatjuk a kiszolgáló működését. 
Amint a múltkori alkalommal megtanultuk, a Cyrus fel- 
ügyeleti fiókjainak nevét a /etc/imapd.conf fájlban szereplő 
admins változó adja meg. 

Másodszor a cyradm ugyanazt a hitelesítési eljárást hasz- 
nálja, mint a Cyrus IMAP egyéb részei. Előző írásomban 

ezt úgy határoztuk meg, hogy a /etc/imapd.conf fájl 

sasl. pwcheck method változóját sas lauthd értékre állítot- 
tuk, a /etc/sysconfig/saslauthd fájl módosításával pedig 

LDAP illetve SuSE-terjesztésnél PAM használatát írtuk elő. 

A PAM ezt követően a /etc/pam.d/imap és a /etc/openldap/ 
ldap.conf fájl segítségével vehető rá arra, hogy az IMAP- 
tranzakciók hitelesítéséhez LDAPF-ot használjon. Magyarul, 

a cyradm a rendszergazdákat is LDAP-on keresztül azonosítja 
és hitelesíti, feltéve, hogy az előző alkalommal leírtak alapján 
helyesen állítottuk be a Cyrus IMAP LDAP-támogatását. 
Végül a hitelesítés elvégzéséhez a cyradm egy LDAP auth ke- 
resést végez a megadott felhasználónévvel és jelszóval, keresé- 
si szempontként az UID LDAP-jellemzőt használva. Ha tehát 
egy fiókot fel szeretnénk hatalmazni a cyradm futtatására, ak- 
kor a hozzá tartozó LDAP-bejegyzésnek UID és userPassword 
jellemzőt egyaránt tartalmaznia kell. Az UID kötelező jellem- 
ző, a userPassword pedig megengedett, mint a posixAccount 
objektumosztály része. Minden IMAP-felhasználó fiókját hoz- 
zá kell tehát rendelni a posixAccount osztályhoz. 

Az utolsó dolog: az OpenLDADP-kiszolgáló /etc/openldap/ 
kat kell megadnunk, amelyek a userPassword jellemzőhöz 
hozzáférést engednek az IMAP-kiszolgáló (illetve a hozzá 
tartozó sas lauthd folyamat) által az LDAP-kiszolgálóhoz 
való csatlakozáshoz, vagyis a hitelesítésekhez használt 
LDAP-felhasználó számára. Az LDAP ACL-utasítások leírása 
a slapd.conf(5) súgóoldalon található, illetve korábbi, , Hite- 
lesítés LDAP használatával (3. rész)" című cikkemben 
(Linuxvilág, 2003. szeptembere) is ismertettem őket. 

A cyradm jellemzően felügyeleti parancssorként fut, nem 
normál parancsként. Elindítása után a cyradm bekéri fel- 
használónevünket és a felügyelni kívánt gép nevét, majd 
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a megfelelő jelszót is. Sikeres hitelesítés esetén felhasználói 
beavatkozást igénylő (interaktív) munkamenetet indít, en- 
nek saját parancsai és beépített súgója van. A cyradm fel- 
használói beavatkozást nem igénylő módon is futtatható, 

a parancsfájlok írásával kapcsolatban pedig a cyradm(1) sú- 
góoldalon találunk útmutatást. 

A cyradm meghívásának legegyszerűbb módja: 


bash-$5 cyradm --user felhasználónév gépnév 


Ha a cyradm-et ugyanazon az állomáson futtatjuk, mint 
amelyen a Cyrus IMAP-ot, akkor a localhost gépnevet ad- 
juk meg, ha viszont távoli gépet szeretnénk felügyelni, ak- 
kor annak nevére vagy IP-címére lesz szükség. Alapbeállítás 
szerint a cyradm a 143-as TCP-kapun keresztül próbál csat- 
lakozni. Mivel a Cyrus IMAP ezt a kaput csak nyílt, szöveg 
alapú kapcsolattartásra használja, a --port kapcsolóval kell 
jeleznünk a programnak, hogy a ILS titkosítású adatkap- 
csolathoz a 993-as számú ICP-kaput szeretnénk igénybe 
venni: --port 993. Szerintem ilyen esetben az a legegysze- 
rűbb, ha a távoli IMAP-kiszolgálóra SSH-n keresztül lépünk 
be, majd helyben futtatjuk a cyradm-ot. 

legyük fel, hogy az IMAP-kiszolgálómon helyben akarom 
futtatni a cyradm-et, és felügyeleti fiókom neve mick admin. 
A kiadandó parancs a következőképpen fest: 


bash-$ cyradm -u mick admin localhost 
IMAP Password: fert 


localhostz 


A localhost: parancssor megjelenése jelzi, hogy a cyradm 
parancssori munkamenetét sikeresen elindítottuk. Ha a ren- 
delkezésre álló parancsok teljes listáját meg szeretnénk jele- 
níteni, adjuk ki a help parancsot vagy gépeljünk be egy 
kérdőjelet. Összesen húsz parancs létezik, mindegyiket rö- 
vidíteni lehet, sokszor kétféle módon is. A súgó képernyő- 
jén a parancsok összes változata megjelenik. 


Postaládák létrehozása a cyradm segítségével 
Postaládát a createmai Ilbox paranccsal tudunk létrehozni, il- 
letve használhatjuk a parancs create vagy cm rövidítését is: 


localhosts cm user.bwooster 
localhostsz 


Ennél hatékonyabb nem is lehetne a parancssor használata. 
Egy apróságot megjegyeznék, a postaládához tartozó fel- 
használónév nem user.bwooster, hanem egyszerűen 
bwooster. A user. előtagot a Cyrus IMAP-postaládák létreho- 
zásakor mindig meg kell adni. Ha tehát a Bubba felhaszná- 
lónak postaládát szeretnénk adni, a cm user . bubba paran- 
csot kell kiadnunk. Ezt követően a postaládán belül a cm 
user . bubba. sent, a cm user .bubba.drafts stb. parancsok- 
kal hozhatunk létre alkönyvtárakat. 

A user. előtag csak a Cyrus és a felügyeletét végzők szá- 
mára látható. Amikor Bubba az Evolution vagy valamely 
más IMAP-ügyfél segítségével csatlakozik a kiszolgálóhoz, 
akkor csak egy Inbox nevű könyvtárat fog látni, függetlenül 
attól, hogy felhasználóneve wser.bubba. Az alkönyvtárak 
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is sent, drafts stb. névvel jelennek meg, az Inbox alatt. 
Érdemes még megemlíteni, hogy a postaládák létrehozása- 
kor a Cyrus semmilyen visszajelzést nem ad arról, hogy 

a műveletet sikeresen végrehajtotta-e. Akit ez — hozzám 
hasonlóan - idegesít, az a listmai Ibox, röviden az Im pa- 
ranccsal ellenőrizheti, hogy éppen milyen postaládák van- 
nak a rendszerben: 


localhosts lm 
user.bwooster (MHasNoChildren) 


Hisszük vagy sem, a Cyrus IMAP ezt követően készen áll 
arra, hogy fogadja a bwooster felhasználó leveleit, illetve le- 
vélolvasási lehetőséget adjon számára. Feltéve, hogy létezik 
egy bwooster UID jellemzőt tartalmazó LDAP-bejegyzé- 
sünk. Cyrus IMAP alatt az új postaláda létrehozásával egy- 
ben a megadott felhasználó IMAPt-fiókja is létrejön. Mielőtt 
azonban áttérnénk arra, hogy a Postfix MTA-t hogyan 

kell rávenni a levelek Cyrus IMAP-nak való továbbítására, 
néhány szó a Cyrus IMAP ACL -jeiről, vagyis hozzáférés- 
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vezérlési listáiról. 


A Cyrus IMAP hozzáférés-vezérlési listái 

Egy Cyrus IMAP alapú rendszer minden postaládájához 
egy vagy több hozzáférés-vezérlési lista (ACL) tartozhat, 
ezek azt határozzák meg, hogy az egyes felhasználók mi- 
lyen műveleteket hajthatnak végre az adott postaládán 
vagy könyvtáron. Alapesetben egy új postaládához csak 
egyetlen ACL tartozik, ez teljes felügyeleti jogot ad a posta- 
láda gazdájának a ládára. 

Érdekes, hogy a rendszergazdák alapesetben csak keresési 
és felügyeleti jogosultsággal rendelkeznek a postaládákra, 
vagyis a listmai lbox paranccsal megtekinthetik a ládák 
nevét, illetve módosíthatják a rájuk vonatkozó ACL-ek tar- 
talmát. Ebből fakadóan, ha törölni akarunk egy postaládát, 
akkor először létre kell hoznunk egy olyan ACL-t, amely 
felügyeleti jogot ad felügyeleti fiókunk számára. Nem hibá- 
ról, hanem biztonsági szolgáltatásról van szó, amely segít 
megelőzni a véletlen törléseket. 

Példánknál maradva, az imént létrehozott postaládát 

a mick admin felügyeleti fiók használatával az alábbi paran- 
csokat kiadva törölhetjük: 


$ cyradm -u mick admin localhost 
IMAP Password: fit 


localhosts setaclmailbox user.bwooster mick admin 
szall 
localhosts deletemailbox user.bwooster 


A második parancsot talán nem nagyon kell magyarázni, 
az első elemein viszont érdemes végigmenni. Itt a cyadm 
setaclmai lbox parancsát adtuk ki, ezt sam vagy setacI! 
formában rövidíthettük volna. A parancsot a kérdéses pos- 
taláda neve követi (uwser.bwooster), majd annak a fióknak 

a neve következik, amelynek jogot szeretnénk adni (szük- 
ség esetén a jogok megvonását is hasonló módon végezhet- 
jük el), ebben az esetben mick admin. Utolsó elemként en- 
gedélykódok csoportját vagy egy különleges karakterláncot 
kell megadnunk. A példában az al 1! karakterláncot látjuk, 
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ennek segítségével az összes engedélyt megadhatjuk vagy 
elvehetjük. A user.bwooster postaládát úgy is tudtuk volna 
törölni, hogy a parancs végére c betűt írunk be, vagyis pos- 
taláda és alpostaládák létrehozására és törlésére adunk jo- 
gosultságot. Az ACL-ekben szereplő további engedélyek 
összefoglalása az táblázatunkban szerepel (60. CD Magazin/ 
MAP könyvtárban). 

Az ACL-ekről a cyradm(1) súgóoldal és a Cyrus IMAP html- 
formátumú leírásában olvashatunk részletesebben. Min- 
denkinek javaslom, hogy miután a cyradm segítségével lét- 
rehozta a postaládákat, minden alkalommal legalább ellen- 
őrizze az ACL-ek tartalmát, ha nem is változtatja meg őket. 
Sok helyen nincs szükség arra, hogy a felhasználók alap- 
értelmezett c (létrehozási és törlési) joga megmaradjon. 

Ha például minden alpostaládát (wser.felhasznalo.sent, 

user. felhasznalo.saved stb.) saját kezűleg hozunk létre, akkor 
előfordulhat, hogy a felhasználók számára nem akarjuk en- 
gedélyezni újabbak létrehozását vagy a meglévők törlését. 


A Postfix beállítása a levelek Cyrus IMAP-nak történő 
továbbítására 

Az első részben már volt szó a levélszállító ügynökök (Mail 
Delivery Agent, MDA) szerepéről: ezek juttatják el a levele- 
ket a postaládákba. Mint MDA, a Cyrus IMAP képes a leve- 
lek postaládákba juttatására, ám ehhez előbb meg kell kap- 
nia őket valamilyen levéltovábbító ügynöktől (Message 
Iransfer Agent, MTA). A legnépszerűbb MTA a Sendmail, 
de ha egyszerűbb és biztonságosabb megoldásra vágyunk, 
válasszuk Wietse Venema kiváló programját, a Postfixet 

(2 http:/www.postfix.org). Mivel én is a Postfixet haszná- 
lom MIA-ként, és a legtöbb Linux-terjesztésben vagy 
alapértelmezett, vagy választható MIA-ként megtalálható, 
a továbbiakban csak vele foglalkozom részletesebben. 
Vajon az IMAP-kiszolgálónak a helyi szervezet SMIP- 
továbbító gépén kell futnia? Lehetőség nyílik rá, de nem 
muszáj így lennie. Biztonság és teljesítmény szempontjából 
ellenben előnyösebb, ha az SMIP-továbbító kizárólag ezt az 
egy feladatot látja el. Ekkor az IMAP-kiszolgáló saját Postfix- 
példányt futtathat, amely a kinevezett (dedicated) SMIFP- 
továbbítótól fogadja a leveleket, és nem közvetlenül más há- 
lózatok MIA-itól. Bármilyen hálózati felépítést is választot- 
tunk, a továbbiakban feltételezzük, hogy az az MIA, amelytől 
az IMAP-kiszolgáló a leveleket kapja, ugyanazon a gépen fut, 
mint a Cyrus IMAR 

Ahhoz, hogy a Postfix a Cyrusnak továbbítsa a leveleket, 
három állományt kell átszerkeszteni. Az első a /etc/postfix/ 
main.cf, ebben az alábbi sort kell a megjegyzésből kivenni, 
vagy ha hiányzik, begépelni: 


mailbox transport - cyrus 


A második fájl a /etc/postfix/master.cf, ebben két sort kell ha- 
sonló módon élesítenünk: 

cyrus unix - n n - - pipe 
user-cyrus argv-/usr/zlibexec/cyrus/deliver -r 

s $íisenderl $íusert 


Lehet, hogy a saját rendszerünkön a második sor más lesz, 
a Cyrus deliver program meghívásának módja az idők so- 
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rán módosult. Ha a Cyrus IMAP és a Postfix telepítését egy- 
aránt saját Linux-terjesztésünk legújabb változatának CD- 
éjéről vagy letöltési helyéről végeztük, akkor az abban talált 
l/etc/postfix/master.cf fájlnak módosítás nélkül működnie 
kell. Ha viszont a Cyrus IMAP vagy a Postfix akár csak egyi- 
két is forrásból tettük fel, akkor szükségünk lehet némi bar- 
kácsolásra, ekkor a Google segítségével deríthetjük ki a má- 
sodik sor helyes formátumát és tartalmát. Erről egyébként 
annyit érdemes leírni, hogy az argv-/usr/libexec/ 
cyrus/deliver átadott értékben szereplő elérési útnak 

a helyi rendszer Cyrus deliver parancsára kell mutatnia. 

A harmadik és egyben utolsó Postfix fájl a /etc/aliases. Egyes 
rendszereken a /etc/postfix/aliases név alatt szerepel. Ha- 
csak nem LDAP-ot használunk az álnevek kikeresésére 

- ennek tárgyalása meghaladná írásom kereteit, de a szél- 
jegyzetben kitérek rá -, akkor az aliases fájlban minden 
Cyrus postaládához léteznie kell legalább egy bejegyzés- 
nek, továbbá a postaládákhoz igényelt álneveket is fel kell 
sorolni. Például a Bubba felhasználó számára az alábbi sor- 
ral kell bővíteni a /etc/aliases állományt: 

bubba: bubba 


Egyszerű, igaz? Elmarad a user. előtag, és a Cyrus postalá- 
dákra felhasználónév alapján hivatkozunk. Ha a Cyrus-, va- 
gyis LDAP-felhasználónevek egyeznek a helyi rendszerben 
szereplő felhasználónevekkel, akkor ezekhez a felhaszná- 
lókhoz nem kell álnév-bejegyzéseket létrehoznunk. 

A Cyrus egyik szépsége, hogy használatakor a felhaszná- 
lóknak nem kell héjhozzáférést adnunk. 

Ha Bubba az adott cég marketingelemzője, akkor hozzáad- 
hatjuk az alábbi sort is: 

marketing zseni: bubba 


Az aliases fájl szerkesztése után ne feledjük el kiadni 
a postalias parancsot, amely létrehozza az új álnév-adat- 
bázist: 


bash-$5 postalias hash:/etc/aliases 


Összegzés 

lermészetesen még sok mindennel tisztában kell lennünk, 
hogy Cyrus IMAP rendszergazdának vallhassuk magunkat, 
ám az eddigiek alapján bele tudunk kezdeni egy LDAP- 
képes Cyrus IMAP-kiszolgáló üzemeltetésébe. A két írásom 
alapján elsajátított tudásanyag elegendő ahhoz, hogy bo- 
nyolultabb kérdésekkel is foglalkozhassunk, mint például 
az LDAP-jelszavak módosításának lehetővé tétele a felhasz- 
nálók számára, az LDAP-kiszolgáló beüzemelése telefon- 
könyvként, megosztott IMAP-könyvtárak biztonságos be- 
állítása, biztonságos webes levelezőfelület létrehozása, 
például a SguirrelMail telepítésével és így tovább. 
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Írjunk hibátlan programot! 


Bár e gondolat túlzó, a jellemző memóriahibákra azonnal rámutat a KDE-csoport 


legújabb csodája, a Valgrind. 





dinamikus memóriakezelés alapvető fontosságú 
szerepet játszik napjaink alkalmazásaiban. Jelen- 
leg elképzelhetetlen C/C-- -- programot írni 


a mal locO vagy newO használata nélkül. E függvények al- 
kalmazásával nem nehéz elérni, hogy az egyetlen korlát az 
elérhető memória mérete legyen. Ám az áldásos tulajdonsá- 
gok mellett hamar napvilágot láttak a gondatlanságból ere- 
dő káros mellékhatások is: a tömbök túlcímzése, lefoglalt te- 
rületek többszöri felszabadítása vagy a mutatóik elvesztése, 
ezek mind-mind olyan gondok, amelyek nem is biztos, 
hogy azonnal kiderülnek. Sőt, még ha rá is jövünk, hogy 
baj van, a gond forrását akkor is órákba telhet megtalálni, 
mivel többnyire egyáltalán nem ott helyezkednek el, ahol 
észleltük őket. 

A Valgrind egy nyílt forrású segédeszköz a memóriakezelési 
hibák felderítésére. Az x86-os processzorra fordított progra- 
mokban figyeli a memóriaszivárgást és a helytelen elérést. 
Julian Seward fejlesztette. Jelenleg ez a projekt 

a 5 http:/www.developer.kde.org/—sewardj/ címen érhető 
el. A Valgrind telepítésének előfeltétele a legalább 2.2-es vál- 
tozatszámú rendszermag, illetve a 2.1-es vagy 2.2-es Glibc 
megléte. 

A Valgrind valójában egy dinamikusan összeépített könyv- 
tár, ez a parancsfájl végzi az összeépítést. A szükséges függ- 
vénykönyvtárak a /usr/local/lib alatt találhatók. A Valgrind 
az alábbi hibákat képes felderíteni: 


e olyan memóriaterület olvasása, amely nem kapott kez- 
deti értéket; 

e — felszabadított terület olvasása, illetve írása; 

e — túlcímzett terület olvasása, illetve írása; 

e a verem nem megfelelő területeinek olvasása, illetve írása; 

e  memóriaszivárgás; 

e — rosszul használt mal loc/new/newL] és free/delete/ 
delete[] páros; 

e a POSIX pthread API helytelen használata. 


Ezek a hibák többnyire összeomláshoz vezetnek, ám sok- 
szor nagyon sokáig rejtve maradnak a felhasználók elől. 
Csak bizonyos körülmények együttálláskor kerülnek fel- 
színre, emiatt nagyon veszélyesek. A Valgrind közvetlenül 
a futtatandó állományt használja a vizsgálathoz. Eldönti, 
hogy a program módosítása szükséges-e a memóriakezelés 
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szempontjából helyes használathoz, és rámutat a hiányos- 
ságokra. Mindezt valójában az x86-os processzor emulálásá- 
val teszi. 

A fentebb említett tulajdonságok következtében a Valgrind 
használata meglepően egyszerű. Első megközelítésben elég 
csak a parancs elé beszúrni a valgrind szót. A futtatandó 
program és kapcsolói előtt a Valgrindnek is megadhatunk 
bizonyos értékeket, ezekkel befolyásolhatjuk a vizsgálatot. 
A továbbiakban jellegzetes programozói hibákat fogok elkö- 
vetni és a Valgrind segítségével derítem fel őket. A példák 
természetesen olyanok lesznek, amelyekről üvölt, hogy hi- 
básak, de most tegyünk úgy, mintha nem is lenne olyan 
szemet szúróak. A hangsúly most a hiba típusán van. 
Készítsünk mi is olyan feltételt, amelyben egy kezdőérték 
nélküli változó áll. Íme: 


finclude cstdio.hs 

int main 0 ( 
signed char a; 
if (a 5 0) printf (hellom"); 
return 0; 


d 


Amennyiben gcc-t használjuk, a -Wall segítségével előcsalo- 
gathatjuk a fordítás alatt az összes figyelmeztető üzenetet. 
Az a szép ebben a csúnyaságban, hogy a gcc még a -Wall-lal 
is rendben találja, azaz szó nélkül lefordítja. Az, hogy az 
elkészült program kiírja-e, hogy hello, vagy sem, nagyban 
függ az ózonlyuk méretétől, és a New York-i tőzsde pilla- 
natnyi állásától. Nézzük, mit mond rá a Valgrind: 


--3220-- Conditional jump or move depends on 
s uninitialised value Cs) 

-—-3220-- at 0x80483FA: main (elso.c:4) 
-—3220-—- by 0x4025614E: . libc start main 
s (in /1l1ib/libc-2.2.5.so) 

53220-— by 0x8048330: (within 

sz /home/bw/prog/c/valgrind/elso) 


A sor elején látható szám az indított folyamat azonosítója 
(PID). Az elkövetett hiba ismertetése után a hívás helye is lát- 
ható. Amennyiben a -g kapcsolóval fordítottuk a programot 
(debug), akkor még a forrásállományban kérdéses sor sorszá- 
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mát is megadja. Ez az alapvető hiba más formában is testet 
ölthet. Például egy tömböt indexelünk a változóval egy szám- 
lálós ciklusban. Gondoljuk csak végig a következményeket. 
Lássunk példát a dinamikus memóriafoglalásra is! Ezúttal 
túlcímzünk egy tömböt: 


finclude cstdio.hs 
finclude cstdlib.hs 
int main 0 ( 
int "p, a; 
p —- (int ") malloc (sizeof (int) " 10); 
pl10] - 1; 
a - pl10]; 
free (p); 
return 0; 


Mivel C-ben a tömbök indexelése 0-tól indul a fenti példában 
a 9-es a legmagasabb indexű elem. A p[10]-zel láthatóan túl- 
címeztük a dinamikusan foglalt tömbünket. Linux alatt elin- 
dítva egyetlen árva hibaüzenetet sem kaptam. Szó nélkül le- 
futott a program. Doktor Valgrind itt is segít (1. lista). 


--3269-- Invalid write of size 4 

sz 09—— at 0x804844E: main (harmadik. c:6) 
s 2 69—— by 0x4025614E: . libc start main 
s (in /11b/libc-2.2.5.so) 

sa. 0b9——- by 0x8048370: (within 

sz /home/bw/prog/c/valgrind/harmadik) 

S 2 09—- Address 0x4107004C€C is 0 bytes after 
sa block of size 40 alloc"d 

3269 at 0x40027B88: malloc 

sz (vg.replace mal loc.c:153) 

sz3269-- by 0x804843F: main (harmadik.c:5) 
5—-3269—-—- by 0x4025614E: . libc start main 
s (in /11b/libc-2.2.5.so) 

5.-3269—— by 0x8048370: (within 

sz /home/bw/prog/c/valgrind/harmadik) 

-—3269—-— 

--3269-- Invalid read of size 4 

SAO 9 at 0x804845A: main (harmadik.c:7) 
-53269-—- by 0x4025614E: . libc start main 
s (in /1ib/libc-2.2.5.so) 

5—3259—-- by 0x8048370: (within 

sz /home/bw/prog/c/valgrind/harmadik) 

-—3269—— Address 0x4107004C is 0 bytes after 
sa block of size 40 alloc"d 

53209 at 0x40027B88: malloc 

sz (vga.replace mal loc.c:153) 

-—-3269—— by 0x804843F: main (harmadik.c:5) 
523269—- by 0x4025614E: . libc start main 
mm (in /11b/libc-2.2.5.so) 

53269—-— by 0x8048370: (within 

sz /home/bw/prog/c/valgrind/harmadik) 


Javítsuk ki fenti programunkat. Ám mialatt jóízűen szür- 
csölgetjük kávénkat, egy vicces kolléga belenyúlt a mun- 
kánkba, és a biztonság kedvéért még egyszer felszabadítot- 
ta a memóriaterületet: 
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finclude cstdio.hs 
finclude cstdlib.hs 
int main 0 ( 
int "p, a; 
p - (int ") malloc (sizeof (int) " 10); 
pl9] - 1; 
a - p[(9]; 
free (p); 
free (p); 
return 0; 


Erre már a Linux is dobott egy , Segmentation fault" üzenetet. 
Ez az a pont, amikor egy több ezer soros program esetén 
Valgrind nélkül nem marad más, mint a gdb (GNU debugger) 
alkalmazása. A változókövetés, töréspontok elhelyezése, és lé- 
pegetés a sorok között hadművelet több órát is elrabolhat 
drága időnkből. Ehelyett inkább a következőket tegyük: 


--3296--— Invalid freeO / delete / delete[] 
23295 at 0x40027E7A: free 

sz (vg.replace mal loc. c:231) 

::3296—- by 0x8048479: main (harmadik. c:9) 
53296 by 0x4025614E: . libc start main 
sz (in /11b/libc-2.2.5.so) 

szí2z9bez by 0x8048370: (within 

sz /home/bw/prog/c/valgrind/harmadik) 

sz3295-- Address 0x41070024 is 0 bytes inside 
sza block of size 40 free"d 

szzz9bsez at 0x40027E7A: free 

sz (vg.replace mal loc. c:231) 

-3295-- by 0x804846A: main (harmadik. c:8) 
553296-—z by 0x4025614E: . libc start main 
s (in /11b/libc-2.2.5.so) 

-53296—-- by 0x8048370: (within 

sz /home/bw/prog/c/valgrind/harmadik) 


A Valgrind hasonlóan jól felismeri, ha a mal locO) mellett 
nem freeO-t, hanem delete0-t használunk. A memória- 
foglalással kapcsolatos függvények bármely helytelen variá- 
ciója esetén jelez. Még abban az esetben is kapunk hibaüze- 
netet, ha a lefoglalt és felszabadított területek megegyez- 
nek, de rossz volt a függvényhívás. 

Utoljára, a rám legnagyobb hatást gyakorolt tulajdonságot, 
a memóriaszivárgás felismerését hagytam. Akadnak olyan 
C-ről szóló könyvek, amelyekben azt tanácsolják, hogy ha 
,nem tudjuk, hol vagyunk éppen", inkább ne használjuk 

a freeO-t, mert a többszöri felszabadítás rosszabb, mintha 
egyszer sem tennénk. Ez Linux alatt még működhet is, 
mert többé-kevésbé eltakarítja a fel nem szabadított terüle- 
teket. Ám más rendszerek esetén ez a memória szabályos 
felfalásához, rosszabb esetben a teljes összeomláshoz vezet- 
het. Azért, mert a rendszertől nem kapunk hibaüzenetet, 
amiért nem szabadítottuk fel a memóriát, még nem járunk 
el helyesen. 

Készítsünk egy memóriafalót: ugyanazt a mutatót fogjuk 
használni többszöri mal loc() hívásra, természetesen free() 
nélkül. Érdekes kipróbálni, hogy egy terminálablakban fut- 
tatjuk memóriafalónkat, mellette pedig egy xosview-t figye- 
lünk. Érdemes elüldögélni előtte. 


finclude cstdio.hz:s 
finclude cstdlib.hs 
int main 0 ( 
int hamm — sizeof (int) " 
for (i — 1; 1 c 5; 144) ( 
1f (NULL -—— (p - (int ") malloc (hamm))) 
break; 
printf (" "Lenyelve: Xd byte.Mm", 1" 


1024, "p, i; 


hamm) ; 
s 
return 0; 


J 


Nem kell megijedni, ugyanis ha Linux alatt futtatjuk, több 
mint valószínű, hogy visszanyerjük a memóriát. A Valgrind 
mindenesetre nem állja meg szó nélkül. 

A --1eak-check-yes beállítás használata esetén az alábbi 
jelentést kapjuk: 


--3400-- 4096 bytes in 1 blocks are possibly lost 
sz-in loss record 1 of 2 

-—-3400-- at 0x40027B88: malloc 

sz (vg.replace mal loc.c:153) 

--3400—— by 0x804845B: main (negyedik.c:6) 
-53400-——- by 0x4025614E: . libc start main 

s (in /1ib/libc-2.2.5.so) 

ss3400-—- by 0x8048370: (within 
/home/bw/prog/c/valgrind/negyedik) 

--3400-- 
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--3400-- 16384 bytes in 4 blocks are definitely 
sz. lost in loss record 2 of 2 

-—-3400--— at 0x40027B88: malloc 

s (vag.replace malloc.c:153) 

--3400—— by 0x804845B: main (negyedik.c:6) 
:53400—— by 0x4025614E: . libc start main 

ss (in /1lib/libc-2.2.5.so) 

::3400-— by 0x8048370: (within 

sz /home/bw/prog/c/valgrind/negyedik) 


Miként az látható, lesznek feltehetően és biztosan elvesztett 
területek. Ötször futott le a ciklusunk, ez azt jelenti, hogy 
négyszer írt felül egy olyan mutatót, ami értékes területre 
mutatott. Ez a négy biztosan elvesztett terület. A program 
végére még maradt egy mutató az adatterületre, így nem 
biztos, hogy ez elveszett. 

Mindent egybevetve nagyon hatékony és jól használható 
eszköz a Valgrind. Nem hallottál még róla, és azt gondolod, 
senki nem használ egy ilyen , névtelen" programot? Látogass 
el a honlapjára és nézd meg, mely nagy alkalmazások készí- 
tésénél vették igénybe a Valgrindet. Az OpenOffice.org-tól 

a Mozillán keresztül számtalan nagy csomag esetén használ- 
ják hibakeresésre. Itt az idő, hogy megismerj egy olyan esz- 
közt, melynek megtanulása tíz perc, de órányi keserves ke- 
resgélést takaríthatsz meg vele. Sok szerencsét és kísérletez- 
gető kedvet a programozáshoz. 


Fülöp Balázs 





2004. június 21 


e ELL 


0 Kiskapu Kft. Minden Jog fenntartva 


0 Kiskapu Kft. Minden Jog fenntartva 


A Redacle munkafolyamat-irányitó rendszer 


Egy MySOL alapú rendszer kezeli egy ötszázezer alkatrészból álló új tudományos 
műszer megépítési folyamatának az adatkezelését, minőségellenőrzését és 
könyvelését. Hogyan alkalmazhatjuk ezt a módszert saját gyártófolyamatainkhoz? 


szubnukleáris részecskék valóban igen kismé- 
retűek, kimutatásukhoz és megmérésükhöz hatal- 
mas érzékelőkre van szükség. Ezt a tudomány- 
területet nagy energiájú fizikának (high-energy physics, 
HEP) nevezik, a kísérleti HEP pedig napjaink egyik él- 
vonalbeli tudományterülete. Felhasználja és továbbfejleszti 
a legújabb módszereket, új eszközöket talál fel, és ösztönzi 
az ismeretek cseréjét. Mindezen okokból kifolyólag a HEP 
már hosszú ideje a nyílt forrású programok birodalma. 

A rossz hír az, hogy a HEP időközben egyre bonyolultabbá 
vált: ami korábban kisipari módszerekkel is előállítható volt, 
az mára ipari folyamat, ami a különleges célra létrehozott 
és rendszerint igen drága folyamatirányító programot is 
megkívánja. Mindezt saját tapasztalataink alapján állít- 
hatjuk: egy nagy nemzetközi csoport egy 12 500 tonnás de- 
tektor, a CMS (Compact Muon Solenoid) legyártását rendel- 
te meg, amelynek a Genovai CERN-ben, a nagy hadronüt- 
köztetőben kellene 2007-ben az adatokat összegyűjtenie. 

Az Olaszországi Nukleáris Fizikai Intézet (INEN) által támo- 
gatott, Rómában, a La Sapienza Egyetem fizikai tanszékén 
működő csoportunk dolgozik az elektromágneses kalori- 
méter megépítésén. A kaloriméter körülbelül ötszázezer al- 
katrészból áll, amelyek között szcintilláló kristályok és foto- 
érzékelők is vannak. A folyamatnak adatkezelői, minőség- 
ellenőrzői és könyvviteli támogatásra van szüksége, ame- 
lyek mindegyike a munkafolyamat-irányításra támaszkodik. 





A 


A munkafolyamat-irányítás 

Egy munkafolyamat-irányító rendszer (Work-flow Manage- 
ment System, WEFM5) ,olyan számítógépes program, amely 
teljesen vagy részben biztosítja az üzleti folyamatok önmű- 
ködővé tételét, miközben dokumentumok, információk vagy 
feladatok áramlanak az egyik résztvevőtől a másikig bizo- 
nyos eljárási szabályok szerinti művelet elvégzése céljából" 
(2 http:/www.e-workflow.org). A WEMS használata egy 
koordinátort feltételez, aki meghatározza a termék előállítá- 
sához szükséges tevékenységek egymáshoz kapcsolódását. 
Az operátorokat az előállítási folyamaton vezetik végig, 
amelyből minden nem várt eltérés kiszűrésre kerül. Mind- 
egyik művelet valamilyen adatot — méretadatot, megjegy- 
zést, jelölést — állít elő, amelyek egy adatbázisba kerülnek. 
Ezt megelőzően gyártófolyamatunkhoz körülbelül két évig 
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1. kép A mai nagy energiájú fizika egy ipari folyamatra hasonlít 


használtunk egy zárt összetevőkre épülő WFMS-rendszert, 
de ez nehézkesnek, lassúnak, túl erőforrás-igényesnek, 

a kényszerű megszakítások után nehezen újraindíthatónak 
és más eszközökkel csak fáradságos módon integrálhatónak 
bizonyult. Amikor a beérkező kaloriméter-alkatrészek emel- 
kedő számával az összeszerelési sebesség már nem tudott 
lépést tartani, úgy döntöttünk, hogy nyílt forráskódra épülő 
összetevőkből fejlesztjük ki a saját megoldásunkat. Célunk 
az volt, hogy ezzel a lépéssel elkerüljük a korábbi hátrá- 
nyokat, és a bejövő és kimenő adatok számára létrehozott 
felületek átlátszóságával biztosítsuk a rendszer kívánt ru- 
galmasságát. A rendszer működtetéséhez a LAMP (Linux, 
Apache, MySOL, és PerI/PHP/Python) felületet választottuk. 
A LAMP minden összetevőjének megvan a maga elsődleges 
feladata: a Linux és az Apache biztosítja a szolgáltatások és 
a programozás alapvető hátterét, a MySOL képviseli WMFS- 
rendszerünk adatbázis-hátterét, a Per/PHP pedig az ope- 
rátorok és az adatbázis közti párbeszédet kezeli. 


Redacle: az adatházisterv 

WEMS rendszerünk neve Redacle (Relational ECAL Data- 
base at Construction Level - relációs ECAL-adatbázis ter- 
vezési szakaszban). Az adatbázistervvel szemben támasztott 
elvárásaink részleteiben a következők voltak: 


e ET 


1. Nagyfokú rugalmasság: az adatbázis felépítése új 
termékek vagy tevékenységek hozzáadásakor nem 
változhat meg. 

2. Minőségellenőrző (OC) adatok tárolásának a lehetősége: 
munkánk fontos részét képezi a minőségbiztosítás, az 
összegyűjtött adatoknak pedig statisztikai elemzés 
céljából bárki számára elérhetőnek kell lennie. 

3. Az adatelérés sokfélesége: az adatbázisnak rendelkeznie 
kell a különböző eljárással — a héjból, Programokból, 
parancsfájllal és a weben keresztül — történő lekérdezés 
lehetőségével. 


Harmadik elvárásunknak a MySOL minden további nélkül 
megfelelt; egyszerűsége és a teljessége mellett ez volt az 

a tulajdonsága, ami miatt a LAMP alkalmazása mellett dön- 
töttünk. Az első két igény kielégítéséhez egy sablon alapján 
egy táblakészletet fejlesztettünk ki, amely — az objektumköz- 
pontú programozáshoz hasonlóan - gyakori 
szabványos módja egy adott probléma meg- 
oldásának. Követett mintánk neve homo- 
morfizmus, ami a sok-egy kapcsolat egy- 
szerű megvalósítása. A gyakorlatban ez úgy 
működik, hogy az alkalmazott folyamat 
minden része rekordként az adatbázis két 
táblájában jelenik meg: az objektumtáblá- 
ban és az objektummeghatározási táblában. 
Minden objektummeghatározás egy azo- 
nosítóval rendelkezik, ez a gyakorlatban 

a MySOL elsődleges kulcsértéke. Sok objek- 
tum használja ugyanazt az objektummeg- 
határozást, a köztük lévő kapcsolatot az ob- 
jektumtáblában tárolt idegen kulcs biztosít- 
ja, amely a megfelelő objektummeghatáro- 
zás azonosítója. 

lalán egy példán keresztül bemutatva vilá- 
gosabb lesz a működés. Mint a bevezetésben 
említettem, kaloriméterünk nagyon sok kü- 
lönböző típusú alkotóelemből tevődik össze. 
Az egyes alkotórészfajtákból, mint amilyen 
például egy kristály, igen sokra van szükség, a kaloriméter- 
hez például összesen mintegy 75 ezer kristályra. Az alkotó- 
részek és meghatározásaik az adatbázis két külön táblájában 
kerülnek tárolásra, ahogy az 1. és a 2. táblázatban látható. 

Egy alkatrészfajta különböző példányai ugyanazt a megha- 
tározást osztják meg a partDpefinition id oszlopban lévő 
megfelelő alkatrész-azonosítón keresztül. Ebben a két 
táblában a 33105000006306 számú alkatrész egy IL típu- 

sú hengeres kristály, ahogy azt a partDefiniton táblában 

a partpefinition id 195-ös értéke is mutatja. 

Ennek a megközelítésnek az igazi előnye a rugalmasságá- 
ban rejlik. Ha bármilyen okból kifolyólag új alkatrészek ke- 
rülnek a képbe, a Redacle adatbázis-szerkezete változatlan 
maradhat. Elegendő a meghatározások táblájában egy új 
rekordot létrehozni és az új elemekkel összekapcsolni. Sőt 

a Redacle adatbázisa még ennél is rugalmasabb: ha kalori- 
méterek helyett autókat gyártanánk, akkor is ugyanez le- 
hetne az adatbázis-szerkezet. 

A tevékenységek ugyanennek a megközelítésnek az alapján 
kerültek leképezésre: egy Activity nevű tábla tárolja az 
ActivityDescription táblában leírt rekordokat. Egy újabb 
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2. kép Egy öt kristályból álló 
egység vizsgálata jellemzőinek 
meghatározása céljából. 
Az eszközöknek a mérési 
adatokat a munkafolyamat- 
kezelő rendszernek kell 
továbbítaniuk 








tevékenység felvétele a munkafolyamatba nem áll többől, 
mint hogy a leírását elhelyezzük a meghatározások táblájá- 
ban és összekapcsoljuk az Activity táblában lévő előfordu- 
lásokkal. Ugyanúgy igaz erre a szerkezetre is, hogy átszabás 
nélkül ráhúzható egy teljesen más üzleti tevékenységre is. 
Ha például levélkézbesítésről lenne szó, akkor a meghatá- 
rozások táblájának rekordjaiban a levélfelvétel, a továbbítás 
és a kézbesítés helyén történő munkaműveletek leírását 
találnánk, míg az Activity tábla rekordjaiból azt tudhatnánk 
meg, hogy mikor és mely küldeményeken végezték el az 
adott műveletet. 

A munkafolyamatot a munka során elvégzendő műveletek 
meghatározásai és e műveletek elvégzési sorrendje hatá- 
rozza meg. A felületet biztosító program ellenőrzi, hogy 

a munkafolyamat-meghatározásban az adott alkatrészen 
végrehajtott műveletet követő tevékenység a megadott 
időn belül befejeződik-e. A műveletek a csatlakozó prog- 
ramnak megfelelően megismételhetőek 
vagy átugorhatók. 

A minőségellenőrzés adatai számára az 
elvonatkoztatás újabb szintjét bevezetve 
ugyanezt a homomorfikus mintát alkalmaz- 
tuk. Olyan tulajdonságadatokat határoz- 
tunk meg, amelyeket egy alkatrészen vég- 
zett adott művelet végzése során gyűjtünk 
össze. Az ezeket tartalmazó Characteristic 
tábla azonban nem tartalmaz valósi érté- 
keket, mivel ezek különféle természetű ada- 
tok lehetnek: karakterláncok, számok vagy 
még összetettebb típusok. A Characteristic 
tábla egyszerűen a kulcsok tárolóhelye, 
amelyek közül az egyik a tulajdonságot 

a charDefinition táblában lévő meghatá- 
rozásával kapcsolja össze. A tényleges 
tulajdonságok értékei különböző, a típu- 
suknak megfelelő táblákban kerülnek 
tárolásra. A mi folyamatunk háromféle 
adattípussal dolgozik: egyszeres lebegőpon- 
tos számokkal, számhármasokkal és karak- 
terláncokkal. Például egy kristály hossza egy egyszerű 
szám, és a Value táblában tárolódik. Néhány mérés a kris- 
tály tengelyének különböző pontjain történik, eltérő kö- 
rülmények között. Az egyik ilyen az optikai terjedés, ame- 
lyet eltérő hullámhosszok mellett 2 centiméterenként 
mérünk. Az eredmények számhármast alkotnak: az első 
szám jelenti a pozíciót, a második a hullámhosszt, a harma- 
dik pedig a hullámterjedés mértékét. Ezek a számhármasok 
képezik a multiValue tábla egy-egy rekordját. Ugyanez igaz 
a karakterláncokra is: az operátorok minden művelet előtt 
szemrevételezik a kristályokat, és megjegyzéseket hagyhat- 
nak a lehetséges hibákra vonatkozóan. A 2-6. táblázatban 
láthatók az imént említett, a jellemzők tárolására szolgáló 
táblák. A 33101000018045 rész a hossz és terjedés mérésére 
(I TO) vonatkozik. A hossz 229,7815 mm a Value táblában. 

A char. id mező 134821, amely a Characteristic táblában 

a charpefinition id-6 értékre mutat, amely a kristály 
hosszának felel meg. A TIO egy számhármasokbál álló 
halmaz a multiValue táblában. Az adott kristály szemrevé- 
telezésének az eredménye a charValue táblában található 
nonhomogeneous (nem homogén) megjegyzés. 
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Ez az eljárás a Redacle-t megint csak másféle folyamatok 
kezelésére is alkalmassá teszi: egy tehenészetben például az 
előállító (karakterlánc) mellett jellemzésként 
használhatnánk az egyes tejadagok baktériumtartalmának 
rögzítésére. Iovábbá a séma megzavarása nélkül adhatunk 
teljesen új adattípusokat (képeket vagy hangokat) az adat- 
bázishoz -— egyszerűen egy új tábla létrehozásával. Például, 
ha képeket szeretnénk hozzáadni, akkor ezt egy három 
mezőből álló tábla létrehozásával érhetjük el, amelyben 

a három mező az elsődleges kulcs, a kép adatai BLOB típus- 
ként és a Characteristic táblához kapcsolódást biztosító 
egész típusú azonosító. A MySOL-ben ezt a táblát az alábbi 
kóddal hozhatjuk létre: 


CREATE TABLE picture ( 
id INT NOT NULL AUTO INCREMENT, 
data BLOB, 
char id INT, 
INDEX (Cchar id), 
PRIMARY KEY (id) 
jú 


A Redacle csatolófelületei 

Programunkban az adatbázissal a felhasználók számos kü- 
lönböző módon kerülhetnek kapcsolatba: a MySOL-ügyfél- 
programon keresztül, C-t --- és Java-programok segítségé- 
vel, Perl-parancsfájlok vagy weboldalakon szereplő PHP- 
parancsfájlok révén. Számottevő előnyei vannak, ha a grafi- 
kus felhasználói felület (GUI) létrehozására böngészőprog- 
ramot használunk: ezzel a GUI hordozhatóvá válik és szük- 
ségtelenné teszi különleges összetevők telepítését, nem 
vesztegetjük az időnket a grafikus felület létrehozására, 
továbbá a böngészőprogram mind az operátorok, mind 
pedig az ügyfelek számára jól ismert. 

A Redacle egy másik kiemelkedő tulajdonsága a más gépek 
felé irányuló csatolófelülete. A kaloriméter szerelésének fo- 
lyamán önműködő szerkezetek végezték el a kristályokkal 
kapcsolatos méréseket, mindenfajta emberi beavatkozás 
nélkül (2. kép). Ezeknek a gépeknek tehát képesnek kell 
lenniük a Redacle rendszerrel való kapcsolattartásra, hogy 
a végrehajtandó műveletek megfelelő sorrendjére, a mű- 
veletek kezdeti és befejező időpontjára és a tulajdonságként 
tárolandó adatokra vonatkozó információkat kicserélhessék. 
Olyan rendszer létrehozása volt a célunk, amely szinte 
bármilyen eszköz számára lehetővé teszi, hogy a Redacle 
rendszerrel kapcsolatba lépjen. Szándékosan kerültük, 
hogy egy adott programozási nyelv hatása alá kerüljünk, 
vagy hogy programozói könyvtárakat biztosítsunk a szóba 
jöhető eszközökhöz, mivel ez amúgy sem állna arányban 

a beszerezhető eszközök mennyiségével, és beágyazott 
eszközök is léteznek zárt programokkal. 

Ehelyett egy Instrument Agent (IA, eszközközvetítő) nevű 
démont fejlesztettünk ki, amely csatolófelületként működik 
a Redacle és az eszköz között. Az IA egy olyan munkafolya- 
mat, amely egy internetes kapura csatlakozva onnan ASCII 
karaktereket képes olvasni, illetve ilyeneket tud oda külde- 
ni. Így az eszköznek csak arra kell képesnek lennie, hogy 

a hálózatra csatlakozzon és karakterláncokat küldjön a kap- 
csolaton keresztül. 
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1. táblázat A Redacle adatbázisának Part táblája 


HÉ partDefinition id 
39105000006306 196 
29105000006307 196 
99105000006308 197 
s0105000006808 198 
28 1050000068 10 196 


2. táblázat A charDefinition tábla 


Z (result of visual vs IOPER 2 
inspection 


26 ! transversal Ne mmánm$F9o 4 
transmission 


A műveletek sorrendje a következő: 

e A csatlakozás után az eszköz bejelenti, hogy mely 
alkatrészen végez műveletet. 

e Az IA lekérdezést hajt végre a Redacle adatbázisában és 
megkeresi a munkafolyamatban az adott alkatrészen 
legutóbb befejezett tevékenységet. Az eszköz által 
futtatandó parancs az adatbázis activityDefinition 
táblájának leírómezőjében található. 

e Az IA elküldi az eszköznek a megfelelő parancsot. 

e A parancs felismerése után az eszköz futtatja a paran- 
csot, az IA pedig a nyugtázás után egy új tevékenységet 
szúr be a Redacle adatbázisba. 

e . A munkafolyamat befejeztével az IA frissíti az imént 
létrehozott tevékenységet, befejezettnek jelöli meg és 
XML formátumú karakterláncok formájában beolvassa 
az eszközről az adatokat. 





A művelet eredménye mul tivalue vagy charvalue 
mezőket egyaránt tartalmazhat. Az egyedül álló értékek 
formátuma a következő: 
cxRE:cFI:mezőnévaVAszmezőértékc/VAsc/FI5 . . . £/REz 


Az cXRE: jelentése eredmény (result), az cFI: a mező 
(field), a CVA: pedig az érték (value) rövidítése. A mező- 
névből az eszközközvetítő megszerzi a tulajdonság megha- 
tározásának azonosítóját, és kitölti a mezőérték formátumá- 
nak megfelelő tábla (value a számok és charvalue a karak- 


terláncok esetén) mezőjét. A multiValue tábla feltöltésére 
akkor kerül sor, ha az eredmény az alábbi formátumú: 


£ARE3-NT3n-es név 
cFIsmezőnév-xAVAsmezőértékc/VAsc/FIs 


£/NT53c£/RE3 
AZ c2NT: ebben az esetben n-est jelöl, vagyis n számú elem- 
ből álló értéket. 


charDenontelpertld 


activity. id 


char id 


Gharáte 





Az eszköz programfejlesztőinek nem kell ismerniük 

a Redacle adatbázisának részleteit, mindössze a használt 
karakterlánc-formátumokról kell tudomást szerezniük. Nin- 
csenek előírt programkönyvtárak, sem csatolandó fájlok; 

a programozási nyelv sem mérvadó. Az egyetlen előfeltétel, 
hogy képes legyen hálózatos kapcsolatot létesíteni az esz- 
közközvetítővel. 

A felhasználói és eszközfelület mellett a koordinátorok és 
felügyelők számára egy parancssoros parancsfájlgyűjte- 
ményt fejlesztettünk ki, továbbá egy kis programkönyvtárat 
hoztunk létre az adatbázis feletti C-- 4 - és Perl-parancs- 
fájlok futtatására, amely feleslegessé teszi az SOL-lekér- 
dezések szerkesztését. 


Tapasztalatok és távlatok 


A Redacle rendszert laboratóriumunk négy hónappal az első 
projektmegbeszélés után bocsátotta ki. A teljes rendszer kö- 
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rülbelül tízezer Perl, C----, PHP és Java nyelven megírt prog- 
ramsort tartalmaz. A program futtatásához szükséges gép a 
korábbi rendszer erőforrásigényével összehasonlítva kicsinek 
mondható. Az előtte használt rendszerrel a kétprocesszoros 
300 MHz-es Pentium kiszolgálógép szinte állandó százszáza- 
lékos processzorterheléssel futott a teljes 515 MB RAM fog- 
laltsága mellett. Szükség volt az ügyfélgépek továbbfejlesz- 
tésére is, a Java GUI támogatása céljából megkettőztük a 
memúóriájukat. Az előző rendszer teljesítményét növelendő 

a tervezett gép egy kétprocesszoros, 1 GHz-es Pentium III 
processzorokat magában foglaló, 1 GB memóriával rendel- 
kező gép volt. A Redacle használatával ez bőven elégnek bi- 
zonyult, a processzorterhelés elhanyagolható, a felhasznált 
memória pedig 140-200 MB. 

Nyilvánvalóvá vált, hogy olyan eszközökre van szüksé- 
günk, amelyekkel az előző, más laboratóriumban még min- 
dig használt adatbázisból adatokat importálhatunk, illetve 
abba exportálhatunk. Ezeket az XML -fájlokat író és olvasó 
eszközöket Perlben gyorsan létrehoztuk, és egy nap alatt 
képesek voltunk minden régi adatot átemelni a Redacle 
rendszerbe. 

Pillanatnyilag mintegy 13 ezer alkatrészt tárolunk az adat- 
bázisban. A tárolt tulajdonságok száma 97 ezer, amelyek 
közül az 50 MB-os teljes adatbázisban bármelyik különböző 
értékekből állhat. A 15 tábla közül a multiValue tábla a leg- 
nagyobb, több mint egymillió rekordot tartalmaz és 41 MB 
méretű. 

A leglátványosabb eredményt azonban az operátoroknak 

a kaloriméter szerelésével töltött idejének terén értük el. 

A Redacle bevezetése előtt az operátorok idejük egynegye- 
dét a munkafolyamat-kezelő rendszerrel való párbeszéddel 
vesztegették el. A Redacle használatával az operátorok és 
az adatbázis közti párbeszédre fordított idő mennyisége 
elhanyagolható, ami nagymértékben növeli az érzékelő- 
összeszerelés hatékonyságát. 

Mi több, az operátorok rövid időn belül hozzászoktak 

a Redacle rugalmasságához és sorra jelezni kezdték az új 
eszközök és csatolófelületek iránti igényüket. Aminek a 
kifejlesztéséhez korábban hetekre volt szükség vagy szinte 
lehetetlen volt megépíteni, a Redacle és a LAMP használa- 
tával most rövid időn belül (néhány órától egy-két napig 
terjedő idő alatt) megvalósíthatóvá vált. 

A Redacle adatbázisának rendkívüli rugalmassága sok más 
üzleti folyamatban vagy ipari területen való felhasználásra 
is alkalmassá teszi, világossá téve, hogy a nyílt forrású prog- 
ramok mennyivel jobban használhatóak lehetnek zárt kódú 
megfelelőiknél. Jövőbeli terveink között még összetettebb 
munkafolyamatmodellek kidolgozása és a gyakran használt 
lekérdezésekből és függvényekből egy programkönyvtár 
összeállítása szerepel, amelyet más Redacle-alapú projek- 
tekben lehetne felhasználni. 
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A merevlemez figyelése Smarttal 


Az egyik merevlemez tán épp jelezni próbál, hogy az utolsókat rúgja. Telepítsünk 
olyan programot, ami figyelmeztet, ha cserélni kell. 


z tény, hogy a merevlemezek néha elhaláloznak, 
A az is könnyen belátható miért. Egy korszerű meg- 

hajtóban a lemeztányérok másodpercenként több 
mint száz fordulatot tesznek meg, miközben az olvasófej és 
az adatokat hordozó mágneses felület között mindössze 
szubmikronnyi távolság van. A merevlemezek gyakran 
egész nap, a hét összes napján, túlfűtött környezetben, 
agyonterhelt vagy alig karbantartott gépekben üzemelnek. 
Ennek megfelelően nem meglepő, hogy a tapasztalt fel- 
használók számára már ismerősek a kimúló merevlemez tü- 
netei. Furcsa dolgok kezdenek történni. Rendszermag hiba- 
üzenetek töltik meg a konzolt, majd a rendszer megbízha- 
tatlanná lesz és lefagy. Gyakran egész napok elmennek az 
elveszett munka megismétlésével, az operációs rendszer új- 
ratelepítésével és az adatok helyreállításával. Még ha létezik 
is biztonsági mentés, egy váratlan lemez-meghibásodás fel- 
ér egy kisebb csapással. 


Mi az a Smart? 

Számos felhasználó, sőt még rendszergazda sem tudja, 
hogy a legtöbb korszerű AIA és SCSI merevlemez fel van 
szerelve egy önellenőrző, értékelő és hibajelentő, más né- 
ven SMARI (Self-Monitoring, Analysis and Reporting 
lechnology) rendszerrel. A Smart merevlemezek figyelik 

a saját egészségi állapotukat és teljesítményüket. Sok eset- 
ben a meghajtó maga figyelmeztet, hogy valami gond adó- 
dik, ezzel segít elkerülni a fentebb vázolt helyzetet. A Smart 
legtöbb megvalósítása lehetővé teszi a felhasználó számára 
azt is, hogy önellenőrzéseket végezzen a merevlemezen és 
számos teljesítmény- és megbízhatósági jellemzőt figyelem- 
mel kísérjen. 

Végzettségemet tekintve fizikus vagyok. A kutatócsopor- 
tom egy nagy számítógéptelepet üzemeltet 300 csomópont- 
tal és 600 merevlemezzel, ezek több mint 500 TB-nyi fizikai 
adatot tárolnak. Néhány évvel ezelőtt kezdtem érdeklődni 
a Smart iránt, amikor rájöttem, hogy segíthet csökkenteni 
az állásidőt és megbízhatóbbá teszi a telep működését. Pont 
ezért körülbelül egy évig karbantartottam a UCSC 
smartsuite programcsomagból származó, nyílt forrású 
smartmontools csomagot. Ebben a cikkben elmondom, ho- 
gyan kell használni a smartmontools smartct] segédprog- 
ramját és a smartd démont a merevlemezek állapotának fel- 
ügyeletére. A 3 http:/smartmotools.sourceforge.net 
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1. lista A smartctil -i a /dev/hda kimenete 


Device Model: IC35L120AvV2O7-O 


Serial Number: VNVDO2G4G3R72G 
Firmware Version: V240A63A 
Device is: In smartct] database 


[for details use: -P show] 
ATA Version is: 6 

ATA Standard is: ATA/ATAPI-6 T13 1410D 
revision 3a 

Available - device has SMART 
capability. 

Enabled 


SMART support is: 


SMART support is: 


webhelyen megtalálhatók a programok és a telepítés leírá- 
sa, S nem szabad elmulasztani a WARNINGS fájl tanulmá- 
nyozását, amelyben a hibás meghajtók, illetve vezérlők lis- 
tája található. A programok használatának leírása egyéb- 
ként a súgóoldalakon, illetve a weboldalon is megtalálható. 
A smartmontools megtalálható Slackware, Debian, SuSE, 
Mandrake, Gentoo, Conectiva és más Linux-változatokban 
is. A Red Hat jelenleg elérhető termékeiben az UCSC 
smartsuite-féle smartct!1 és smartd található, de az elkö- 
vetkezendő változatokban már a smartmontools változat 
lesz beépítve. 

Ahhoz, hogy megértsük a működését, segítségünkre lehet, 
ha megismerjük a történetét. Az eredeti Smart megvalósítá- 
sait (specific SFF-30351) a merevlemezgyártók egy csoportja 
készítette. A 2. Revision szerint (1996. április) a lemezek bel- 
ső listát vezetnek harminc jellemzőről, ilyen például az ol- 
vasás és keresési hibák aránya, amelyekkel a megbízhatósá- 
got és a teljesítményt mérik. Mindegyik tulajdonságnak 
(attribution) egy bájtos normalizált értéke (Value) van, ami 
1-től 253-ig terjedhet, valamint ehhez kapcsolódik egy egy 
bájtos határérték (treshold). Ha egy vagy több tulajdonság 
értéke (Value) kevesebb vagy egyenlő, mint a hozzátartozó 
határérték, akkor a merevlemez vagy várhatóan meghibá- 
sodik az elkövetkezendő 24 órában, vagy meghaladta a ter- 
vezett, illetve üzemi élettartamát. Néhány érték a meghajtó 
működése közben frissül, míg mások csak külön próba el- 
végzése során, ami a meghajtó írás- és olvasás teljesítményét 
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2. lista A smartctl kimenete a -Hc /dev/hda 


SMART overal1]-health self-assessment test result: PASSED 

General SMART Values: 

off-line data collection status: (0x82) offline data collection activity 
was completed without error. 

Auto Off-line Data Collection: 

Enabled. 

Self-test execution status: ( 0) The previous self-test routine 
completed without error or no 
self-test has ever been run. 

Total time to complete off-line 

data collection: (2855) seconds. 

offline data collection 

capabilities: (0x1b) SMART execute offline immediate. 
Automatic timer ON/OFF support. 
Suspend offline collection upon new 
command. 
offline surface scan supported. 
Self-test supported. 

No Conveyance Self-test supported. 
No Selective Self-test supported. 

SMART capabilities: (0x0003) Saves SMART data before entering 
power-saving mode. 

Supports SMART auto save timer. 

Error logging capability: (0x01) Error logging supported. 

General Purpose Logging supported. 

Short self-test routine 

recommended polling time: ( 1) minutes. 

Extended self-test routine 

recommended polling time: ( 48) minutes. 


lelassítja, így külön paranccsal kell futtatni őket. 1995 végén 
az SFF3035i egyes részei beolvadtak az AIA3 szabványba. 
Az ATA-4 szabvánnyal elvetették azt az igényt, hogy a me- 
revlemezek egy belső Attribútum táblát vezessenek. Ehe- 
lyett a meghajtók egyszerűen egy OK vagy NOT OK választ 
adnak az egészségük felől érdeklődő kérdésre. A negatív 
válasz azt jelzi, hogy a meghajtó gyári programja 
(firmware) úgy látja, a meghajtó várhatóan meg fog hibá- 
sodni. Az ATA-5 szabványba bekerült egy AIA hibanapló és 
a Smart parancskészlete bővült a merevlemez önellenőrzést 
futtató parancsaival. 

Ahhoz, hogy ezeket a tulajdonságokat kiaknázzuk, tud- 
nunk kell hogyan használjuk a smartmontools-t a lemez 
Attribútum-ainak vizsgálatára (a legtöbb meghajtó 
visszirányban csereszabatos (backward-compatible) az SFF- 
80351-vel), a meghajtó egészségi állapotának lekérdezésére, 
önellenőrző tesztek futtatására, a meghajtó önellenőrző 
próbanaplójának (ez az utolsó 21 nap próbaeredményeit 
tartalmazza) vizsgálatára, a meghajtó ATA hibanaplójának 
(ami az öt utolsó lemezhibájának a részleteit tartalmazza) 
vizsgálatára. Bár ez a cikk elsősorban az ATA meghajtókra 
összpontosít, a smartmontools weboldalán található leírás 
a SCSI merevlemezekről. 

Kezdésnek a smartct! -a /dev/hda parancsot adjuk ki 
rendszergazdaként, a megfelelő útvonalat használva 

a meghajtónkhoz. Ha a Smart nincs engedélyezve a meg- 
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hajtón, először engedélyezni kell a -s kapcsolóval. Ezután 
valami olyasmit fogunk látni, mint az 1.1. listákon. 

A kimenet első része (1. lista) a meghajtótípus és a gyári 
program (firmware) adatait sorolja fel — a példánkban ez 
egy IBM/Hitachi GXP-180. A smartmontools rendelkezik 
egy adatbázissal a meghajtótípusokról, ha a vizsgált meg- 
hajtó megtalálható benne, akkor a nyers tulajdonságadato- 
kat képes helyesen értelmezni. 

A kimenet második részében (2. lista) olvasható a meghajtó 
egészségi állapotát firtató lekérdezés eredménye. Ez az egy- 
soros Executive Summary Report (felügyelői összesítő jelen- 
tés) a lemez állapotáról. A példában látható merevlemez át- 
ment a próbán (passed). Ha azonban a meghajtó egészségi 
állapota FAILING, azonnal készítsünk biztonsági mentést 
az adatainkról. E rész többi adata a lemez kapacitásáról, va- 
lamint a rövid és az átfogó önellenőrző próba lefutásának 
várható időtartamáról nyújt tájékoztatást. 

A kimenet harmadik része (3. lista) a meghajtó belső táblá- 
zatának legfeljebb harminc tulajdonságát sorolja fel (egy 
legfeljebb 255 elemet tartalmazó listából). Ne feledjük, hogy 
ezek a tulajdonságok már nem részei az AIA szabványnak, 
de a legtöbb gyártó még mindig támogatja őket. Bár az SFF- 
80351 nem határozza meg a tulajdonságok jelentésének ér- 
telmezését, soknak létezik ténylegesen szabványos értelme- 
zése. Például ennek a meghajtónak a 13. tulajdonsága (ID 
7194) a belső hőmérsékletet követi nyomon. 
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3. lista A smartctl kimenete a -A /dev/hda 


VvVendor Specific SMART Attributes with Thresholds: 


Szaktekintély NNNN4/7/ LB ]EE— 


ID ATTRIBUTE NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN FAILED RAW VALUE 
1 Raw Read Error Rate 0x000b 100 100 060 Pre-fail Always - 0 
2 Throughput. Performance 0x0005 155 155 050 Pre-fail offline v 225 
3 Spin Up. Time 0x0007 097 097 024 Pre-fail Always - 293 (Average 270) 
4 Start Stop. Count 0x0012 100 100 000 old age Always - 10 
5 Reallocated Sector Ct — 0x0033 100 100 005 Pre-fail Always — 0 
7 Seek Error Rate 0x000b 100 100 067 Pre-fail Always - 0 
8 Seek Time Performance — 0x0005 125 125 020 Pre-fail offline - 36 
9 Power. On Hours 0x0012 100 100 000 old age Always - 3548 
10 Spin Retry Count 0x0013 100 100 060 Pre-fail Always - 0 
12 Power Cycle Count 0x0032 100 100 000 old age Always - 10 
192 Power-Off Retract Count 0x0032 100 100 050 old age Always - 158 
193 Load Cycle Count 0x0012 100 100 050 old age Always - 158 
194 Temperature Celsius 0x0002 189 189 000 old age Always - 29 (Lifetime Min/Max 23/33) 
196 Real located Event Count 0x0032 100 100 000 old age Always - 0 
197 Current Pending Sector 0x0022 100 100 000 old age Always - 0 
198 offline Uncorrectable — 0x0008 100 100 000 old age offline - 0 
199 UDMA CRC Error. Count 0x000a 200 200 000 old age Always - 0 


Tanulmányok megmutatták, hogy a merevlemez hőmérsék- 
letének minimális, 5 "C-kal történő mérséklése jelentősen 
csökkenti a meghibásodási arányokat, ámbár ez a legújabb, 
hidraulikus csapágyazású meghajtóknál már kevéssé érde- 
kes. Az egyik legegyszerűbb és legolcsóbb lépés, amit a me- 
revlemez megbízhatósága érdekében tehetünk az, hogy kü- 
lön ventilátorral hűtjük, közvetlenül ráfújva a hűvös levegőt. 
Minden Attribútum-nak létezik egy hat bájtos nyers értéke 
(RAW. VALUE) és egy egy bájtos normalizált értéke (VALUE). 
Példánkban a nyers érték három hőmérsékletet tárol: a me- 
revlemez hőmérsékletét Celsius fokban (29), valamint az 
élettartama alatti legkisebb (23) és legnagyobb (33) értéket. 
A nyers érték formátuma a gyártótól függ, semmilyen szab- 
vány nem szabályozza. A meghajtó megbízhatóságának 
nyomon követésére a meghajtó gyári programja a nyers ér- 
téket egy 1 és 253 közé eső normalizált értékké alakítja. Ha 
ez a normalizált érték kevesebb vagy egyenlő, mint a határ- 
érték (THRESH), az Attribútum a ,nem megfelelő" jelzést fog- 
ja mutatni, mint az a WHEN FAILED oszlopban látszik. Pél- 
dánkban ez az oszlop üres, mert egyik Attribútum sem lett 
hibára beállítva. A legalacsonyabb (WORST) normalizált érték 
szintén látható. Ez a legkisebb érték, amit a Smart szolgálta- 
tás engedélyezése óta elért a meghajtó. Az Attribútum TYPE 
mezője különbözteti meg, hogy az Attribútum , nem felelt 
meg" beállítása azt jelenti-e, hogy az eszköz elérte a terve- 
zett élettartam végét, vagy pedig azt, hogy hamarosan vár- 
ható a meghajtó meghibásodása. Például a lemez felpörgési 
ideje (ID 73) egy meghibásodást előjelző tulajdonság. Ha 
ez (vagy bármelyik másik előjelző Attribútum) , hibás" érté- 
ket kap, a lemez meghibásodása 24 órán belül válható. 

A tulajdonságok neve, illetve jelentése, valamint a nyers ér- 
tékek értelmezése egyetlen szabványban sincs meghatároz- 
va. A különböző gyártók gyakran ugyanazt a tulajdonság- 
azonosítót használják különböző célokra, ezért a tulajdonsá- 
gok értelmezése módosítható a smartct!] parancs -v kapcso- 
lójával, erről bővebben a súgóoldalakon lehet olvasni. Példá- 
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ul néhány meghajtó a 9-es tulajdonságot használja a meg- 
hajtó üzemidő perceinek tárolására, így a smartct] -v 9 
paranccsal helyesen lehet megjeleníteni a szóban forgó ér- 
téket. Ha a vizsgált meghajtó szerepel a smartmontools 
adatbázisában, ez a hozzárendelés önműködően zajlik. 

A smartct! -a kimenetének része a következő: 


SMART Error Log Version: 1 
No Errors Logged 


Ez a lemezhibák naplója. A szóban forgó meghajtó történe- 
tesen hibátlan, ezért ez a napló üres. Általában csak akkor 
kell aggódni, ha a lemezhibák tömegesen sorakoznak. Vé- 
letlenszerű hibák előfordulhatnak, addig nincs baj, amíg 
nem rendszeresek. A smartmontool weboldalán számos 
példa látható a smartct] -a kimenetről, ezek hibanapló- 
bejegyzéseket is tartalmaznak. A bejegyzésekhez egy idő- 
bélyegző is tartozik, ami a meghajtó élettartamával mérve 
mutatja az előfordulás idejét. Ugyanígy le vannak pecsétel- 
ve azok az önálló AIA parancsok, amelyek a hibát okozták, 
a bekapcsolástól eltelt milliszekundumokat megszámlálva. 
Ez megmutatja, hogy a hiba új vagy régi. 

A smartct1 kimenetének utolsó része (4. lista) jelentés a le- 
mez által futtatott önellenőrző próbákról. E próbáknak két 
típusa használatos: a rövid és hosszú (az ATA-6/7 meghaj- 
tóknak van leszállítás utáni és szelektív önellenőrzése). 
Ezek a smartct! -t short /dev/hda és a smartct! -t long 
/dev/hda paranccsal futtathatók és nem veszélyeztetik 

a meghajtón lévő adatokat. Ezeknek az önellenőrzéseknek 
nincs közvetlen hatása a meghajtó normális működésére, 
ezért a parancsot nyugodtan lehet alkalmazni egy működő 
rendszer csatolt meghajtóján. lelepünk csomópontjain min- 
den vasárnap reggel lefuttatunk egy hosszú önellenőrzést 
a cron segítségével. A 4. lista bejegyzései mind hiba nélkül 
lefutott önellenőrzések; a Lifetime oszlop megmutatja 

a meghajtó bekapcsolt élettartamát az önellenőrzés lefutá- 


sakor. Ha az önellenőrzés hibát talál, az LBA cím megadja 
a hiba pontos helyét. A Remaining oszlop százalékban kife- 
jezve mutatja meg az önellenőrzés hátralévő mennyiségét 
a hiba megtalálásakor. Ha arra gyanakszunk, hogy valami 
gond van a meghajtóval, igen ajánlatos lefuttatni egy 
hosszú önellenőrző próbát, hogy megtaláljuk a gondot. 

A smartct!] -t offline parancs segítségével offline próbá- 
kat lehet végrehajtani. Ezek a próbák nem készítenek be- 
jegyzéseket az önellenőrzési naplóba. Ezek még az SFF- 
30351 szabványból származnak és felfrissítik azoknak az 
Attribútumok-nak az adatait, amelyek normális merevlemez 
működés mellett nem kerülnek frissítésre (lásd az 
UPDATED oszlopot a 3. listában). Néhány meghajtó támo- 
gatja az önműködő offline próbákat, amelyeket a smartct! 
-o on paranccsal lehet engedélyezni. Ennek hatására né- 
hány óránként önműködően lefut egy offline ellenőrzés. 

A Smart szabvány a meghajtók önellenőrzésének futtatásá- 
ra és a teljesítmény bizonyos szemszögből való megfigyelé- 
sére kínál eszközt. Legnagyobb hiányossága, hogy nincs 
egyetlen közvetlen szerkezet az operációs rendszer vagy 

a felhasználó informálására, ha hibát talál. Mivel a meghaj- 
tó Smart állapotát gyakran nem kísérjük figyelemmel, szá- 
mos lemezhiba rejtve marad mindaddig, amíg végzetes 
meghibásodást nem okoz. lermészetesen a felhasználó az 
itt leírtak alapján a smartct 1] használatával rendszeresen el- 
lenőrizheti a meghajtót, de ez nehézkes megoldás. 

A smartmontools csomag eddig még nem említett része 

a smartd démon, mely a rendszeres ellenőrzést végzi, és 

a meghajtók Smart adatait hibára utaló jelek után kutatva 
nézi át. Beállítható, hogyha ilyenre bukkan, küldjön levelet 
a rendszergazdának, vagy futtasson le tetszőleges parancs- 
fájlt. Alaphelyzetben a smartd indulása után bejegyzi 

a rendszer meghajtóit, majd félóránként ellenőrzi állapotu- 
kat, nem megfelelő Attribútum, egészségi állapot vagy nö- 
vekvő számú AIA hiba, nem megfelelő eredményű önellen- 
őrzés után kutatva, s minden ilyen adatot rögzít a SYSLOG 
segítségével a /var/log/messages naplófájlba. 

A /etc/smartd.conf fájl segítségével lehet vezérelni és 
finomhangolni a smartd működését. Ezt a fájlt a smartd in- 
dulásakor, még mielőtt a háttérbe vonulna, beolvassa. Min- 
den egyes sor egy-egy merevlemezhez tartalmaz utasításo- 
kat. A mi számítógép-telepünk csomópontjainak beállítás- 
fájlja így néz ki: 


/dev/hda -S on -o on -a -I 194 -m 
ss senselphys . uwm. edu 
/dev/hdc -S on -o on -a -I 194 -m 
ss senselphys . uwm. edu 


Az első oszlop jelzi az ellenőrzendő eszközt. A -o enge- 
délyezi az önműködő offline kipróbálást, a -S pedig enge- 
délyezi az önműködő tulajdonságmentést. A -m parancs 
a figyelmeztető üzeneteket küldi el az őt követő levél- 
címre, a -a pedig arra utasítja a smartd-t, hogy figyelje 

a meghajtó összes Smart-jellemzőjét. Ebben a beállításban 
a smartd naplóz minden változást az összes normalizált 
tulajdonság értékben. A -I 194 parancs arra szolgál, hogy 
mellőzze az 194. Attribútum változásait, mivel a meghaj- 
tók hőmérséklete gyakran változik, ezért szükségtelen 
rendszeresen naplózni. 
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Normál esetben a smartd-t a Unix normál ini t-je indítja. 
Például a Red Hat-terjesztésben: 

a /etc/rc.d/init.d/smartd start és 

a /etc/rc.d/init.d/smartd stop parancsok használhatók 
a démon indítására és leállítására. 

A smartd és a beállításfájlok használatáról további útmuta- 
tást a súgóoldalakon (man smartd) lehet találni, valamint 
összefoglalva a smartd -D és a smartd -h adnak. Például a 
-M test utasítás egy figyelmeztető próbalevelet küld, hogy 
az elektronikus levelek kézbesítésének helyességéről meg- 
győződhessünk. Más utasítások további rugalmas műkö- 
dést tesznek lehetővé, mint például a nyers Attribútum ér- 
tékek változásának figyelését. 

Mit kell tenni, ha egy meghajtó zavar jeleit mutatja? 

Mi történik, ha egy önellenőrzés vagy a meghajtó Smart 
egészségi állapota nem megfelelő eredményt ad? Először 
is amilyen gyorsan csak lehet, mentsünk minden adatot 

a szóban forgó lemezről egy másik rendszerre. Másodszor 
futtassunk néhány kiterjedt meghajtó-önellenőrzést és fi- 
gyeljük, hogy a hiba megismételhető-e ugyanazon az LBA 
címen. Ha igen, akkor valószínűleg valami baj van a meg- 
hajtóval. Ha a lemez Smart egészségi állapota nem megfe- 
lelőt jelez és még garanciális, a forgalmazó általában ki 
fogja cserélni. Ha a meghajtó önellenőrző tesztje nem meg- 
felelő eredményű, számos gyártó nyújt egyedi meghajtó- 
gyógyító programot, mint például a Maxtor PowerMax 
vagy az IBM Drive Fitness lest. Olykor ezek a programok 
tényleg meg tudják javítani a meghajtót, a hibás szektoro- 
kat kizárják a működésből. Gyakran olyan különleges hi- 
bakódot adnak, amelyet fel lehet használni cserelemez 
igényléséhez. 


Összegzés 

Ez a cikk a smartmontools alapjairól szólt. Ha többet sze- 
retnénk megtudni róla, tanulmányozzuk a súgóoldalakat 
és az internet idevonatkozó oldalait, további segítséget 
pedig a támogató levelezőlistán kaphatunk. Ne feledjük, 
a smartmontools nem helyettesíti az adatmentést! A Smart 
nem képes előre jelezni minden lemez-meghibásodást, de 
gyakran jelzi, hogy valami gond támadt és már eddig is 
számos számítógéptelepnek segített, hogy megbízhatóan 
működjön. 

Néhány fejlesztő átülteti a snartmontool s-t FreeBSD, 
Darwin és Solaris rendszerekre, mi pedig mostanában 
bővítettük ki oly módon, hogy képes legyen megfigyelni 
és vezérelni a RAID-vezérlők mögött lévő AIA-meghaj- 
tókat. Ha szeretnél résztvenni a smartmontools fejlesz- 
tésében, írj a támogató (support) levelezőlistára. Különö- 
sen érdekelnek bennünket a gyártóspecifikus adatok 

a Smart Attribútum-ok és nyers értékek jelentéséről és 
fordításáról. 


Linux Journal 2004. január, 117. szám 


Bruce Allen A Wisconsin Egyetem fizikapro- 
fesszora. A gravitációs hullámok és a nagyon 
korai világegyetem témakörben végez kutatá- 
sokat és számos nagy Linux-telepet épített az 
adatok elemzéséhez. 
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Energiakezelés linuxos rendszerekben 


Az energiakezelés megvalósítása minden rendszerben nehéz feladat. Az alábbiak- 
ban áttekintjük, hogyan tudjuk kezelni gépünk normál üzemi és energiatakarékos 


állapot közötti átmenetelt. 


z energiakezelő programok az akkumulátoros 
AA gépeknél - hordozható számítógépek, tenyérgé- 

pek - szinte léttontosságúak, segítségükkel ugyan- 
is takarékoskodhatunk az energiával, ha az illető eszközt 
nem használjuk folyamatosan. Egyszerű példaként a kijel- 
ző megadott, használat nélkül eltelt idő utáni kikapcsolá- 
sának lehetőségét említeném. Ilyen módszerekkel élve 
meghosszabbíthatjuk az akkumulátoros üzemidőt, vagyis 
hosszabb ideig dolgozhatunk a géppel, mielőtt újra kelle- 
ne töltenünk az akkumulátort. 
Az eszközoldal támogatása az energiakezelés működésé- 
hez elengedhetetlen; ha ez megvan, akkor a programoldal 
feladata a lehetőségek okos kihasználása. Az energiakeze- 
lés támogatásának szintje minden eszköznél más és más. 
Akadnak olyan készülékek, amelyek csak kétféle állapotot 
ismernek, a be- és a kikapcsoltat. Más eszközök, például 
az SA1110 processzor összetettebb energia-megtakarítási 
lehetőségeket is kínálhatnak, mint például az órajel vál- 
toztatása. 
Az energiakezelés megvalósítása minden rendszernél bo- 
nyolult művelet, ugyanis számos, egymással kapcsolatban 
nem álló alrendszer működését kell ugyanolyan irányvona- 
lak szerint összhangba hozni. Írásomban az energiakezelés 
Linux (2.4.x) alatti működését és a fejlett energiakezelést 
támogató, akkumulátoros működésű készülékeken történő 
megvalósítását tekintem át, az illesztőprogramok és az al- 
kalmazások szintjére egyaránt kitérve. 


A két energiakezelési szabvány 

A számítógéprendszerek energiakezelése az évek során 
egyre kifinomultabb lett, eme folyamat során több szab- 
vány is született. A két legnépszerűbb ezek közül az APM 
(Advanced Power Management, azaz fejlett energiakezelés) 
és az ACPI (Advanced Configuration and Power Interface, 
vagyis fejlett beállítás- és energiafelület). Az APM-et a Mic- 
rosoft és az Intel vezette be, az energiakezelés támogatását 
egy vagy több programréteg segítségével valósítja meg. 

A rétegek közötti adatcserét szabványosították. Az APM 
modellben a BIOS kulcsszerepet játszik. A két említett meg- 
oldás közül az ACPI az újabb, fejlesztésében a Ioshiba, az 
Intel és a Microsoft vett részt. Az ACPI intelligensebb ener- 
giakezelést tesz lehetővé, amelyet inkább az operációs rend- 
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szer végez, nem annyira a BIOS. Ugyan ez a két szabvány 
elsősorban x86 alapú gépekben terjedt el, más géptípuso- 
kon is gond nélkül megvalósíthatók. 


Az energiakezelés megvalósítása 

Az energiakezelő eljárások megvalósítása előtt tudnunk kell, 
hogy az eszközoldal egyáltalán milyen szolgáltatások támo- 
gatására képes. Az energiakezelő program egyik legfonto- 
sabb feladata az, hogy minden eszközt olyan állapotban 
tartson, amely a lehető legkisebb energiafelhasználással jár. 
Az energiakezelés kérdéskörének egyik lehetséges megkö- 
zelítésénél a megvalósítást egy energiahasználati—állapot- 
átmeneti folyamatábra felrajzolásával kezdjük. Ebben több- 
féle energiahasználati rendszerállapotot határozunk meg, 
illetve az állapotok közötti átmeneteket kiváltó szabályokat 
és eseményeket is megadjuk. 

Példaként vegyünk egy tenyérgépet, amelyben a következő 
eszközök találhatók: Intel SA1110 processzor, valós idejű 
óra, DRAM, flash, LCD, előlap megvilágítása, UARI, hang- 
kodek, érintőképernyő, gombok és főkapcsoló. Az Intel 
SA1110 processzor több energiamegtakarító szolgáltatást is 
támogat, ilyen például az órajel programból megvalósított 
változtatásának lehetősége. Az órajel csökkentésével a pro- 
cesszor energia-felvétele is csökken - igaz, a teljesítménye 
is. A processzor többféle működési módot is ismer: 


e Futó mód: az SA1110 normál állapota, amelyben valami- 
lyen programkódot futtat. Minden energiaforrás enge- 
délyezett, minden órajel él, a lapka minden erőforrása 
rendelkezésre áll. 

e — létlen mód: lehetővé teszi, hogy a processzort program- 
ból leállítsuk, ha éppen nincsen rá szükség. Ilyenkor 
a processzor órajele megszűnik, ezzel valamennyi ener- 
gia-megtakarítás elérhető. A lapka összes többi erőforrá- 
sa aktív marad. Ha megszakítás érkezik, a processzor 
újra bekapcsol. 

e Alvó mód: a legnagyobb mértékű energia-megtakarítási 
lehetőséget nyújtja, amely egyben a legtöbb szolgáltatás 
kikapcsolásával is jár. Ebben a módban a processzor túl- 
nyomó részének tápellátása megszűnik. Alvó módból 
a processzor előre beprogramozott események hatására 
lép ki, ilyen például a főkapcsoló gomb megnyomása. 


1. ábra Energiakezelési állapotátmeneti folyamatábra 


Mint látható, tétlen vagy alvó módba a programoldal kap- 
csolhatja a processzort. 

Az ilyen tenyérgépekben a DRAM-cellákat a processzorban 
található memóriavezérlő egység rendszeresen frissíti. Alvó 
állapotban azonban a processzor nagy része kikapcsol, va- 
gyis a DRAM-cellák frissítése megszűnik, ez tartalmuk el- 
vesztését okozza. Az adatvesztés elkerülése érdekében 

a legtöbb DRAM támogatja az úgynevezett önfrissítő mó- 
dot, amelyben a DRAM önmaga gondoskodik saját cellái- 
nak fírissítéséről. Ha ez a helyzet, akkor a DRAM - ugyan- 
csak programból megvalósítottan, néhány vezérlőregiszter 
tartalmának megváltoztatásával — a processzor alvó módba 
kapcsolása előtt önfrissítő módba állítható, és ezzel meg- 
őrizhető a tartalma. 

lenyérgépünk fő energiafogyasztó egységei a processzor, 

a memória és a kijelző háttérvilágítása lesznek. Ezeket 

kell tehát a lehető leginkább energiatakarékos állapotban 
tartani. 

Az 1. ábrán a tenyérgéphez látható egy lehetséges energia- 
használati—állapotátmeneti folyamatábra. Röviden tekint- 
sük át az energiaállapotokat: 


e Futó állapot: a rendszer indítás után ebbe az alapértel- 
mezett állapotba jut. Az energiafogyasztás ebben az álla- 
potban a legnagyobb, hiszen minden eszköz aktív vagy 
bekapcsolt. 

e — Készenléti állapot: a rendszer akkor lép ebbe az állapot- 
ba, ha megadott ideig nem használják. Az LCD és a hát- 
térvilágítás kikapcsol, a processzor órajele csökken, ez- 
zel bizonyos mértékű energia-megtakarítás érhető el. 
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e Alvó állapot: a rendszer akkor lép tovább ebbe az álla- 
potba, ha hosszabb időn keresztül nem használják. Az 
energia-megtakarítás érdekében határozottabb lépések 
történnek, a processzort ugyanis alvó módba állítjuk, 
ekkor viszont az egyéb eszközök túlnyomó része is le- 
kapcsol. A DRAM önífrissítő módba lép, ezzel biztosítja 
a gép állapotának, vagyis a memóriába írt adatok meg- 
őrzését. Alvó állapotból a gép előre beprogramozott ese- 
mények hatására léphet ki. Ekkor futó állapotba kap- 
csol, és helyreállítja saját állapotát. 

e Kikapcsolt állapot: a gép a shutdown parancs hatására 
jut ebbe az állapotba. A kikapcsolt állapotból történő ki- 
lépéskor sor kerül a rendszer újratöltésére. Ez azt jelenti, 
hogy nincs szükség a gép állapotának, azaz a DRAM 
tartalmának megőrzésére, vagyis a memória kikapcsol- 
ható. Kikapcsolt állapotban a legkisebb az energiafo- 
gyasztás. 


A valós idejű óra a rendszeridő pontos értéken tartása érde- 
kében minden rendszerállapotban működik. 

A folyamatábra alapján bátran kijelenthetjük, hogy a hasz- 
nálaton kívüliség felismerése és az eszközök alacsony ener- 
giafogyasztású állapotba kapcsolása jelenti az energiakezelő 
program szívét. 


A Linux és az energiakezelés 

Az energiakezelő program az állapotátmeneteket az illesz- 
tőprogramokkal és az alkalmazásokkal együttműködve ve- 
zérli. Minden energiakezelési eseményről tud, ide értve az 
állapotátmeneteket, az alvó módba kapcsolást és az akku- 
mulátor lemerülését is. Ennek köszönhetően a programol- 
dalnak módja van az állapotátmenetek megakadályozására, 
ha valamiért veszélyesnek ítéli meg végrehajtásukat. 

Az illesztőprogramok általában azért is felelősek, hogy ala- 
csonyabb energiafogyasztású állapotukba kapcsolásuk előtt 
mentsék az eszközök állapotát, a rendszer újraaktiválásakor 
pedig helyre is állítsák. 

Az alkalmazások általában nem szólnak bele az energiake- 
zelési állapotátmenetekbe. Előfordulhat azonban, hogy 
olyan, az eszközöket közvetlenül használó programot futta- 
tunk, amely valami miatt mégis részt szeretne venni az át- 
menetekről szóló döntések meghozatalában. Ebben a rész- 
ben áttekintjük, mire van szüksége egy illesztőprogramnak 
ahhoz, hogy az energiakezelésbe beleszólhasson: 


e pm dev adatszerkezet: a Linux-rendszermag energiakeze- 
lő alrendszere a bejegyzett illesztőprogramok számára bi- 
zonyos adatokat a pm dev nevű adatszerkezetbe ír be, így 
tudja értesíteni őket az energiakezelési eseményekről. 

e pm register: az illesztőprogramoknak először be kell 
jegyezniük magukat az energiakezelő alrendszernél, az 
energiakezelésben csak ezt követően vehetnek részt. 
Ezt a pm register függvény meghívásával tehetik meg: 


struct pm dev "pm register(pm dev t type, unsigned 
sz long id, pm callback cbackfn); 


A type az illesztőprogram által kezelt eszköz típusát ad- 


ja meg, az id az eszköz azonosítóját, a cbackfn pedig 
egy mutató az illesztőprogram visszahívó függvényére. 
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2. ábra A rendszer futó állapota 


Az illesztőprogramokban használható típusokat és azo- 
nosítókat a linux/pm.h fájlban lehet megtalálni. Sikeres 
futás esetén a pm register visszatérési értéke egy 

pm dev adatszerkezetre hivatkozó mutató. Az illesztő- 
program visszahívó függvényét az energiakezelő al- 
rendszer hívja meg energiakezelési esemény esetén. 

A függvénynek átadott értékek a következők: 


e dev: mutató az eszközt képviselő pm dev adatszerke- 
zetre, megegyezik a pm register által visszaadott 
mutatóval. 

e event: az energiakezelési esemény típusát adja meg. 

A lehetséges események a következők: 

e PM STANDBY - a rendszer készenléti állapotba fog 
váltani; 

e PM SUSPEND - a rendszer felfüggesztett, alvó állapotba 
kapcsol; 

e PM RESUME - a rendszer visszatér üzemi állapotba, 
akár készenléti, akár alvó állapotból. Megvalósítástól 
függően akár több esemény is megadható. 

e data: a kéréshez tartozó adat, ha van ilyen. 


Minden illesztőprogramtól azt várjuk, hogy az energiakeze- 
lési esemény típusától függően elvégezzen valamilyen mű- 
veletet. A PM SUSPEND esemény hatására, például az LCD 
illesztőprogramjának mentenie kell az eszközállapotot, 
majd ki kell kapcsolnia az LCD-t. A PM RESUME eseménynél 
az LCD illesztőprogram feladata az LCD bekapcsolása és 

a mentett állapot visszaállítása. 

A visszahívó függvénynek egy egész (integer) értékkel kell 
visszatérnie. A nulla visszatérési érték azt jelzi, hogy az 
illesztőprogram elfogadta az energiakezelési eseményt. Ha 
a visszatérési érték nem nulla, akkor az illesztőprogram el- 
utasította az energiakezelési eseményt. Ilyenkor előfordul- 
hat, hogy az állapotátmenet meghiúsul. Ha például az LCD 
illesztőprogram energiakezelő visszahívó függvénye egy 
PM. SUSPEND eseményről kap jelzést, visszatérési értéke pe- 
dig 1, akkor a felfüggesztett állapotba váltás el fog maradni. 
Az illesztőprogramok visszahívó függvényeinek meghívása 
előre meghatározott sorrendben történik. A sorrend felállí- 
tása egyszerű, , később jött, előbb szolgáljuk ki" elv alapján 
történik, ami viszont az eszközök egymástól való függése 
esetén okozhat gondot. Vegyünk példának egy Bluetooth 
eszközt, amelynek csatolófelületét egy USB állomásvezér- 
lőn keresztül érjük el. A Bluetooth illesztőprogramnak 
szüksége van erre a felületre, nélküle nem tud kapcsolatba 
lépni a Bluetooth eszközzel. A függés miatt az USB állomás- 
vezérlő illesztőprogramja a Bluetooth illesztőprogram előtt 
kerül betöltésre. Vagyis az USB állomásvezérlő előbb jegyzi 
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3. ábra A rendszer készenléti állapota 


be magát az energiakezelési eseményekre, mint a Bluetooth 
illesztőprogram. 

Ha a rendszer alvó állapotba szeretne lépni, egy PM SUSPEND 
kérést küld először a Bluetooth illesztőprogramnak, majd 

az USB illesztőprogramnak. Az USB állomásvezérlő 

a PM SUSPEND feldolgozásának részeként gond nélkül lekap- 
csolhatja a Bluetooth kaput. Amikor viszont a rendszer nor- 
mál állapotba vált vissza, a PA RESUME esemény először 

a Bluetooth illesztőprogramhoz jut el, az USB állomásvezér- 
lő illesztőprogramjának értesítése csak ezt követően történik 
meg. Amikor a Bluetooth illesztőprogram feldolgozza, pon- 
tosabban feldolgozná az eseményt, akkor az eszköz felé ve- 
zető csatolófelület még nem áll rendelkezésre, vagyis 

a Bluetooth eszköz felébresztése sikertelen lesz. Az ilyen 
helyzeteket a legegyszerűbben oly módon lehet elkerülni, 
hogy a PM. RESUME eseményekről , elsőként érkezett, elsőként 
szolgáljuk ki" sorrend szerint küldjük ki az értesítéseket. 

A pm unregister függvény meghívásával a megadott 
illesztőprogramot kivehetjük az energiakezelésben résztve- 
vők listájából: 


pm unregister(pm callback cbackfn); 


A bejegyzés törléséhez ugyanazt a mutatót kell átadott ér- 
tékként használni, mint amit a bejegyzésnél is megadtunk. 
Ha egy illesztőprogram törölte saját bejegyzését, az energia- 
kezelő alrendszer többé nem értesíti az energiakezelési ese- 
ményekről. 

A Linux az illesztőprogramok számára két felületet is meg- 
ad, ezek a pm access és a pm dev. idle. A pn access meg- 
hívását az eszköz elérése előtt kell megejteni, 

a pm dev. idle pedig akkor jut szerephez, ha egy eszközt 
nem használunk. Ugyanakkor vegyük figyelembe, hogy 
ezeket a felületeket nem minden géptípuson lehet megva- 
lósítani. 

Példaként lássunk egy átlagos állapotátmenetet, amelyben 
csak illesztőprogramok jutnak szerephez. Az energiakezelő 
alrendszer a nála bejegyzett illesztőprogramokat egy két- 
szeresen láncolt, vagyis körkörösen bejárható listában tartja 
nyilván. A 2. ábrán a lista három illesztőprogram bejegyzé- 
sét követő állapotát próbáltam szemléltetni. Feltételezzük, 
hogy elsőként a C, majd a B és végül az A illesztőprogram 
jegyezte be magát. 

legyük fel, hogy most a rendszer futó állapotból készenléti 
állapotba vált. Az energiakezelő alrendszer PM STANDBY ké- 
rést küld mindhárom illesztőprogramnak. Kétféle ered- 
ményre juthatunk. Az egyik eset az, hogy mindegyik 
illesztőprogram elfogadja a kérést, és a rendszer készenléti 
állapotba lép. A második lehetőség az, hogy valamelyik 





4. ábra Az A illesztőprogram elfogadta a PM STANDBY kérést 


illesztőprogram, esetleg több 
is, elutasítja a kérést. Ilyen- 
kor az állapotváltás sikerte- 
len lesz, a rendszer futó álla- 
potban marad. 

A 3. ábrán látható állapot ak- 
kor alakul ki, ha mindegyik 
illesztőprogram elfogadja 

a PM STANDBY kérést. Vegyük 
észre, hogy a pm. dev adat- 
szerkezetek állapot- (state) 


mezőjének értéke a kérés elfogadását követően megváltozott. 


Most vegyük azt az esetet, amikor az A és a B illesztőprog- 
ram elfogadja a PM STANDBY kérést, a C viszont nem. 

A 4. ábrán az az állapot látható, amikor az A illesztőprog- 
ram már teljesítette a kérést. Miután az A illesztőprogram 
jelezte beleegyezését, a B illesztőprogram is megkapja 

a PM STANDBY kérést. 

Az 5. ábrán az azt követő állapot szerepel, hogy a B illesztő- 
program is jelezte egyetértését. Ekkor az A és a B eszköz 
már készenléti állapotban van, a C viszont még futóban. 

A következő művelet a PM STANDBY kérés elküldése a C il- 
lesztőprogramnak, amely viszont elutasítja őt. Ekkor az ál- 
lapotváltást vissza kell vonni. Mivel az A és a B eszköz már 
készenléti állapotban áll, az energiakezelő alrendszernek 
esetükben vissza kell vonnia a műveletet, vagyis küld ne- 
kik — először a B majd az A illesztőprogramnak - egy 

PM RESUME kérést. A visszavonás elvégzése után újra futó 
módban lesz az összes eszköz, s ez az állapot a 6. ábrán 
látható. 


APM 
A 7. ábrán az APM modell látható. Fontosabb összetevői 
a következők: 


e . APM BIOS: programfelület az alaplaphoz és energiake- 
zelésre képes eszközeihez és összetevőihez. Ez a rend- 
szer energiakezelő programrendszerének legalacso- 
nyabb rétege. 

e APM illesztőprogram: az APM megadott operációs 
rendszeren történő megvalósításáért felelős. 

e . APM támogatással rendelkező illesztőprogramok és al- 
kalmazások: az APM illesztőprogram minden energia- 


kezelési eseménynél velük lép kapcsolatba. 
Az APM BIOS észleli és jelenti a különféle energiakezelési 


eseményeket, mint például az akkumulátor lemerülését, az 
áramforrás megváltozását, a rendszer készenléti állapotba 
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6. ábra A C illesztőprogram elutasította a PM STANDBY kérést, 
ezért a rendszer újra futó állapotba váltott 





5. ábra Az A és a B illesztőprogram elfogadta a PM STANDBY kérést 


való be- vagy onnan kilépé- 
sét stb. Az APM illesztő- 
program rendszeresen le- 
kérdezi az APM BIOS-tól 
az energiakezelési esemé- 
nyekre vonatkozó adatokat, 
majd az APM-képes illesz- 
tőprogramokkal és alkalma- 
zásokkal együttműködve 
dolgozza fel őket. 

A Linux APM illesztőprog- 
ramja két felületet tesz elérhetővé az alkalmazások számá- 
ra. Az első a /proc/apm, amely a rendszer áramforrásáról 

— hálózati forrás vagy akkumulátor - tájékoztat. Ha a gép 
akkumulátorról üzemel, akkor az akkumulátor töltöttségi 
szintjéről és a teljes lemerüléséig hátralévő időről is tájékoz- 
tat. A második felület a /dev/apm-bios, amelynek segítségé- 
vel az alkalmazások értesülhetnek az energiakezelési ese- 
ményekről, illetve részt is vehetnek bennük. Az alkalmazá- 
sok a megfelelő ioct1] hívások révén maguk is kezdemé- 
nyezhetnek állapotátmeneteket. A fájlra vonatkozó olvasási 
hívások mindaddig blokkolva maradnak, amíg valamilyen 
energiakezelési esemény nem történik. Az olvasási hívás 
visszatérésekor a következőként bekövetkező energiakeze- 
lési eseményről kapunk tájékoztatást. 

Előfordulhat, hogy rendszerünkön a /dev/apm. bios fájlt 
megnyitó alkalmazások egy része rendszergazdai jogosult- 
sággal fut. Ezeket az alkalmazásokat az APM illesztőprog- 
ram kiemelten kezeli. Az események egy részéről, mint az 
alvó vagy készenléti állapotba váltás, az APM illesztőprog- 
ram minden olyan alkalmazást értesít, amely megnyitotta 

a /dev/apm bios fájlt. A rendszergazdai jogosultságokkal 
futó alkalmazásoktól visszaigazolást is vár, a tényleges álla- 
potátmenetre csak a beleegyező üzenetek beérkezése után 
kerül sor. Egyetértésüket az alkalmazások az e célra szolgáló 
ioct1] hívásokkal fejezhetik ki. 

Normál esetben a következő ioct! hívások támogatása 
valósul meg: 


e APM IOC STANDBY: készenléti állapotba lépteti 
a rendszert. 

e APM IOC SUSPEND: felfüggesztett állapotba lépteti 
a rendszert. 


Az APM két, felhasználói térben futó segédprogramot is 
rendelkezésünkre bocsát. Az apm parancs a rendszermag 
APM alrendszerével tart kapcsolatot. A neki átadott érté- 
kektől függően képes a rendszer energiaállapotának meg- 
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7. ábra Az APM modell 


jelenítésére, de arra is használható, hogy a felhasználó 
készenléti vagy felfüggesztett állapotba léptesse a gépet. 
Az apmd démon a különféle energiakezelési eseményeket 
jelenti és dolgozza fel, valamint minden energiakezeléssel 
kapcsolatos eseményt naplóz a /var/log/messages fájlba. 

A naplózás mellett az apmd a különféle energiakezelési 
események hatására bizonyos műveleteket is képes végre- 
hajtani, ezek megadására egy parancsfájl, általában az 
apmd proxy fájl szolgál. A parancsfájlt az apnmd démon hív- 
ja meg, és egy vagy két átadott érték segítségével közli ve- 
le, hogy milyen esemény fog bekövetkezni. Nézzünk egy 
példaparancsfájlt: 


case 1:2 1n 


"standby" :") 
HA rendszer használaton kívül van, ezért 
fkészenléti 
fállapotba vált. Csökkentjük a processzor 
ftsebességét. 


echo 162200 5 /proc/sys/cpu/0/speed 


"resume" :"standby") 
HA rendszert használni akarjuk, ezért 
fkészenléti állapotból futó 
ftállapotba hozzuk. Növeljük a processzor 
ftsebességét. 
echo 206400 5 /proc/sys/cpu/0/speed 


"suspend" :") 
HA rendszer felfüggesztett állapotba lép. 
fLeeállítjuk a hálózati csatolót. 
ifconfig ethO0 down 
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8. ábra Példa az állapotátmenet végrehajtására 


"resume" :"suspend") 
HA rendszer kilép a felfüggesztett állapotból. 
fbekapcsoljuk a hálózati csatolót 
ítés növeljük a processzor sebességét. 
ifconfig ethO0 up 
echo 206400 5 /proc/sys/cpu/0/speed 


Példa az energia-állapotátmenetre 

Az állapotátmenetekkel kapcsolatosan homályosnak tűnő 
részek azonnal megvilágosodnak, ha veszünk egy illesztő- 
programokat és alkalmazásokat egyaránt tartalmazó példát. 
legyük fel, hogy a rendszerben két illesztőprogram találha- 
tó, D1 és D2, mindkettő energiakezelésre bejegyezve, vala- 
mint a /devv/apm bios megnyitásával három alkalmazás 

(A, B és C) is résztvesz a folyamatokban. Az A és a B alkal- 
mazás rendszergazdai (superuser, s user) jogosultsággal 

fut, a C pedig normál felhasználóként. 

A 8. ábrán ez a felállás látható. 

Vegyük most azt az esetet, amikor a rendszer futó állapot- 
ból alvó állapotba akar váltani. A szükséges lépések sora az 
alkalmazásoknak (A, B és C) a végrehajtandó átmenetről 
való értesítésével kezdődik. Így az alkalmazások elvégez- 
hetik az általuk az átmenethez szükségesnek vélt művele- 
teket. Mivel az A és a B alkalmazás rendszergazdai jogo- 
sultsággal fut, a további lépések megtétele előtt meg kell 
várni, hogy beleegyeznek-e az átmenet végrehajtásába. 
Amikor az A és a B alkalmazás végzett mindazzal, amit az 
alvó állapotba való átlépés előtt végre akart hajtani, engedé- 
lyező jelzést küld az APM illesztőprogramnak. 

Az APM illesztőprogram most készen áll a rendszer alvó ál- 
lapotba kapcsolására. PM SUSPEND üzenetet küld D1-nek és 
D2-nek. D1 és D2 az általa kezelt eszközt alvó állapotba kap- 
csolja, majd nyugtázó jelzést küld az APM-nek. Miután D1 
és D2 végzett a szükséges műveletekkel, az APM jelzi a pro- 
cesszor energiakezelő illesztőprogramjának, hogy a pro- 
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cesszort alvó állapotba lehet kapcsolni. Amikor ez is megtör- . Anand K. Santhanam (asanthanain.ibm.com) 1999-ben ke- CG 
tént, akkor a rendszer alvó állapotba kapcsolásának folya- rült az IBM Global Services (Software Labs) indiai csapatába. 2 
mata lezárult. Az IBM Linux Group tagja, ahol leginkább illesztőprogramok- 
.. kal, ARMLIinuxszal és a beágyazott rendszerek energiakeze- E 
Összegzés lésével foglalkozik. az 
Ugyan az APM alkalmazásának vannak bizonyos hátrányai 0) 
is, egyszerűségéből fakadóan gyakorlatilag bármilyen ké- Víijay Sukthankar (vksuktha(gin.ibm.com) 1994-ben került az E 
szülékben megvalósítható. Más szabványok, például az IBM-hez. Jelenleg a Linux Competency Center vezetője, fi 
ACPI, magasabb fokú energiakezelést tesznek lehetővé,ám emellett egyéb Linux alapú, nyílt forrású fejlesztéseket is irá- e 
ennek a lehetőségnek a növekvő bonyolultság az ára. nyít. Az IBM különféle munkacsoportjaiban számos beágya- 58 
Fontos az is, hogy minden illesztőprogram és alkalmazás zott Linux alapú szolgáltatás fejlesztésébe kapcsolódott be. k 
helyesen végezze az energiakezelési műveleteket, ellenkező 1 
esetben akár egyetlen illesztőprogram is megakadályozza Murali lyer (mniyergus.ibm.com) 1995 óta dolgozik az IBM- sei 
például azt, hogy a gép felfüggesztett állapotba lépjen. nél, a vállalatnak több laboratóriumában is megfordult világ- zi 
Ugyanakkor hibátlan megvalósítással az energiakezelés je- szerte. 2000. óta Linux alapú beágyazott rendszerek tervezé- . 
lentős mértékben hozzájárulhat a gép hatékonyabb, ener- sével foglalkozik. Többek közt felső kategóriájú tenyérgépek 7 
giatakarékosabb működéséhez. fejlesztésében és szívritmus-szabályzó készülékek progra- o 


mozásában vett részt. 
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Srivatsa Vaddagiri (vsrivatsa(oin.ibm.com) 


1996 óta dolgozik az IBM India alkalmazásában. Számos APM szabvány 
különböző tervezetben vett részt, elsősorban Unix alapú A rendszermag forrásának Documentation/om.txt 
rendszerekkel foglalkozik. Jelenleg a Linux alapú tenyérgé- állománya 


pek energiakezelés-támogatásán dolgozó beágyazott intel SA1110 Advanced Developers kézikönyv 
Linuxot fejlesztő csoport kiemelkedő tagja. 
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Pehelysúlyú ablakkezelők 


Kényelmes géphasználat csekély erőforrásigénnyel. 


ondolom sok Linux-felhasználóban felmerült már 
az a kósza gondolat, hogy miért is kell nekünk fé- 
nyesen villogó, mindenféle különleges szolgáltatá- 
sokat nyújtó, magas színvonalú ablakkezelőt használnunk 
X-felületen? lermészetesen egyáltalán nem kell, viszont 
mindenki a legelterjedtebbek felé veszi az irányt. Nincs 

is ezzel semmi baj, hiszen mindenki szereti, ha minél na- 
gyobb tudású alkalmazások segítik mindennapi munkáját, 
mert végül is gépünket sok esetben a grafikus felületen 
keresztül érjük el. Erre gondoltak a népszerű munkakör- 
nyezetek fejlesztői is annak érdekében, hogy minél széle- 
sebb néptömegeket csábítsanak a Linux használatára. Ab- 
ból indultak ki, hogy az emberek nagy többsége Windowst 
használ, így mindenki megszokta, hogy a felület minden- 
ben a kedvére próbál tenni. Ha jobban belegondolunk, az 
ablakos rendszerben szükségünk is van rá, hiszen más- 
képp nem nagyon tudnánk elérni a mindennap használa- 
tos lehetőségek jelentős részét. Linux alatt azonban kissé 
más a helyzet. Mivel rendszerünk parancssorban gyakor- 
latilag verhetetlen, s a legtöbb guru ennél fogva ideje 
nagy részét a parancssor előtt tölti, ezért számukra sokkal 
kényelmesebb, gyorsabb ezen a felületen keresztül vezé- 
relni a masinájukat, minthogy igénybe vegyék a munka- 
környezet nyújtotta, sokszor nehézkes alkalmazások segít- 
ségét. A legtöbb felhasználó ugyanakkor szívesen mellőzi 
a különböző látványos hatásokat, nem veszi igénybe 

a bonyolult eszközkezelést stb. A kérdés ekkor csupán az, 
miért is foglaljon el a munkakörnyezet sok-sok tárhelyet, 
memóriát, processzoridőt, ha nagyrészt ki sem aknázzuk 
a képességeit? Ha jobban belegondolunk, egy kezünkön 
fel tudjuk sorolni milyen programokat használ egy átlagos 
felhasználó egy beállított rendszeren: parancssor, web- 
böngésző, levelező, médialejátszó, irodai csomag. Ha pe- 
dig ebből a szemszögből vizsgáljuk, bizony sokszor felesle- 
gesnek tűnik a fényes grafikus felhasználói felületek hasz- 
nálata, hiszen e szolgáltatások ellátására csupán egy 
visszafogott tudású ablakkezelő is bőségesen elegendő. 
Főként akkor zavaró mindez, ha nem elég gyors a masi- 
nánk, ezért munkánkat nem hogy javítaná, de jelentősen 
hátráltatja is. Ekkora engedményeket nem is szükséges 
tennünk, ugyanis számtalan úgynevezett pehelysúlyú ab- 
lakkezelő (munkakörnyezet) áll rendelkezésünkre éppen 
az ilyen esetekre a mindennapi felhasználók számára. 
Magam is az egyik ilyen , fapadost" használom, mert bár el- 
fut a KDE, és semmi bajom vele, de ezzel a kis programmal 
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1. kép Az Fvwm nevű klasszikus 


úgy suhan a gépem, mintha legalábbis Windows 95 tanyáz- 
na rajta. Ami a kihasználtságot illeti: minden tekintetben 

a kezem alá dolgozik. 

A következőkben néhány használható és kevésbé hasz- 
nálható ablakkezelőt szeretnék bemutatni, ecsetelni elő- 
nyeiket, vázolni hátrányaikat, s mindezt olyan módon, 
hogy a leggyengébbektől haladunk a legerősebbek felé, 
miközben egyre magasabbra helyezzük felhasználói 
igényeinket. 


Fvwm2 

Ez az ablakkezelő bizony nem mai gyerek, fénykorát 

a Unixok idejében élte, ám ez a fény mára jelentősen meg- 
kopott. Ez nem azt jelenti, hogy nem is használják. Szá- 
mos helyen - főleg távoli X-terminálok esetében — mind 

a mai napig rendeltetésszerűen alkalmazzák. Ami a felépí- 
tését illeti, egy különleges ablakot kapunk, ez ad helyet 

a több munkafelület kezeléséért felelős lapozónak, az órá- 
nak, illetve néhány előre meghatározott gombnak. Ez 

a manapság megszokott startmenü-panelnek tekinthető, 
azaz innen vezérelhetjük az asztalainkon lévő ablakokat. 
Leggyakrabban használt eleme az asztalon bal kattintással 
elérhető menü, amellyel különböző alkalmazásokat indít- 
hatunk, vagy éppen fejezhetjük be az ablakkezelő (ezzel 
együtt az X-felület) használatát. Az ablakok kezeléséről rö- 
viden annyi mondható el, hogy nehézkes, bár ez is csak 


megszokás kérdése. Annyi bizonyos, hogy nem nyújt szá- 
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2. kép A Blackbox nevű ablakkezelő 


Mik ezek a misztikus munkafelületek? 


A Unix háza táján a kezdetektől fogva jellemző vonás 

a különböző X-felületeknél, hogy egyszerre nem csak 
egyetlen képernyőnk van. Ez azt jelenti, hogy több 
munkaasztalt határozhatunk meg, ebből azonban mindig 
csak egyetlenegy látszik. Mindegyikük hajszálra ugyan- 
úgy fest, s ugyanúgy is működik. Szerepük az, hogy 
megsokszorozzák a felhasználó számára rendelkezésre 
álló felületet, amelyen számtalan ablakát szétdobálhatja 
vagy épp rendszerezheti. Az ablakfelületek között általá- 
ban egy lapozó segítségével mozoghatunk. Ez - akár 
menü formájában, akár grafikus módon felkínálja a kü- 
lönböző munkafelületeket, s kattintással kapcsolhatjuk 
be őket - természetesen az összes munkafelületen 
látszódik. Az egyes ablakok esetében lehetőségünk 
nyílik áthelyezni őket, néhol csak az ablak menüjének 
alkalmazásával, máshol azonban a már jól ismert fogd 
és húzd módszerrel. A haladók számára használata 
rendkívül hasznosnak bizonyult, de meg kell jegyezni, 
hogy a csupán webezgető felhasználók e lehetőségtől 
inkább csak eltévednek. Ilyen esetekben ki kell 
kapcsolni a lapozót, és csak az épp jelenlévő felületen 
kell elhelyezni az összes ablakot. 


munkra annyi lehetőséget (például egy egyszerű teljes 
méretűvé alakítást), mint mondjuk a későbbiek során be- 
mutatandó egyéb megoldások. Ezenkívül túl nagy méretű 
a keret, a fejléc, és amint nem talál elegendő helyet egy 
ablaknak az asztalon (mert már sok egyéb ablak van meg- 
nyitva), akkor egy keretet ragaszt az egérmutatóra, és ne- 
künk kell megmondani, hová teheti le az ablakot. Monda- 
nom sem kell, hogy ez hosszú távon az agyára megy min- 
den kulturált ablakkezelőn felnőtt embernek. 
Összességében elmondható róla, hogy az akkori kor színvo- 
nalán egy igen értékes program volt, amely azonban mára 
megöregedett, s inkább csak megszállott szerelmesei hasz- 
nálják, komoly munkára nem való. 
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3. kép Az Afterstep ablakkezelő bevetés közben 
(forrás: 5 http:/Avww.afterstep.org) 


Blackbox 


Az Fvwm-nél ugyan jóval fiatalabb, de fejlesztői — tudását 
tekintve — az erősen ingerszegény kategóriát célozták meg 
vele. A felállás itt is nagyjából ugyanaz: asztal, rajta egy pa- 
nel, amelyen a pillanatnyi munkaasztalt láthatjuk, a jelen- 
leg kiválasztott ablakkal, s a panelen váltogathatunk az 
egyes ablakok, illetve munkafelületek között. Ehhez az asz- 
talon jobb kattintással elérhető rendszermenü adódik, ame- 
lyen rögtön mindenféle egyéb panel nélkül megtehetjük az 
összes beállítást, amit a fejlesztők beépítettek — ebből jól kö- 
vetkeztethető — nem túl sok van belőlük. A rendszer egé- 
szen addig remekül használható, amíg ikon állapotúvá nem 
teszünk egy ablakot, vagyis inkább addig, míg ezt a bizo- 
nyos ablakot újra fel szeretnénk használni, ugyanis ekkor 
kezdődhet az eltüntetett ablak utáni ádáz vadászat. 
Hosszabb-rövidebb keresgélés után általában rájövünk, 
hogy a rendszermenü 

Blackbox/Workspace/Icons/ cablaknév: menüpontjának be- 
kapcsolásával hozhatjuk újra elő. Csúnya hibának tartom, 
hogy ha az ikon állapotú ablak futása megszakad (például 
azt a terminált zárjuk be, amiből indítottuk), akkor ebből 

a bizonyos menüből nem tűnik el az ablak neve, s rákattint- 
va a nagy semmi jő elő az ablak helyett, s ezeket egyszerű 
módszerekkel nem is lehet eltüntetni. Vigasztalódásul 

a sok-sok, változatosnál változatosabb látványtéma (theme) 
próbálgatását javaslom. 

Mindent összevetve elmondhatom, hogy ha nem lenne ott 
az ikonállapotban eltűnő ablakok kínos kérdése, az egyik 
legjobb ablakkezelő lehetne, mert szegényes képességei kö- 
vetkeztében veszett gyors (mintha Windows 3.1-et futtat- 
nánk Pentium 4-sen). 


Afterstep 

Ez is meglehetősen régi ablakkezelő, amely az előző kettő- 
nél megismert sajátosságokat magában hordozza, ám mind- 
ezt fejlettebb formában teszi. Azt is mondhatnám, az előző 
két ablakkezelő előnyös tulajdonságait olyan módon ötvözi, 
hogy eközben a hibáikat nem veszi át. 

Ebben az ablakkezelőben is létezik egy különleges , ablak", 
egy gombpanel (button bar) az asztalon, amely minden 
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4. kép A WindowMaker működés közben 


munkafelületen feltűnik, s szerepét tekintve ez is azt a bizo- 
nyos Start menüt valósítja meg. A grafikus felületen keresz- 
tül sajnos nem lehet testreszabni, ehhez szövegszerkesztő- 
vel kell hozzányúlni a beállításfájlokhoz. Egészében el- 
mondható róla, hogy nehezen és szegényesen szabható 
testre, de mentségére legyen mondva, hogy ezt úgyis csak 
egyszer kell megtennie a felhasználóknak. S ha ezzel meg- 
volnánk, egy az előzőhöz hasonló fürgeségű ablakkezelőt 
kapunk. 

lermészetesen szintén megtalálható benne az asztalról bal 
kattintással előhozható rendszermenü, amelyben az After- 
step saját lehetőségein kívül rendszerünk egyéb alkalmazá- 
sait is elindíthatjuk. Az ablakkal természetesen minden 
megszokott művelet elvégezhető. Ikonállapot alkalmazása 
esetén az ablak úgy jelenik meg, mintha egy ikon lenne az 
asztalon. Az Afterstepnél már megjelenik az a beállítási le- 
hetőség is, hogy az egeret a képernyő széléhez tolva átevic- 
kélhetünk a szomszédos munkafelületre, így gyakorlatilag 
szabadon járhatjuk be a rendelkezésre álló teljes felületet, s 
az ablakok kényelmes áthúzogatásával tényleg úgy érez- 
zük, mintha négyszer akkora monitorunk lenne. 

Bár elsőre rendszertelennek tűnhet ez a kiváló ablakkezelő, 
de aki az elején képes átvészelni a bajos testreszabási mizé- 
riát, az utána biztosan nem fog megválni tőle. 


WindowMaker 


Ezt az ablakkezelőt közelebbről szemügyre véve tapasztal- 
hatjuk, hogy ez igazából az Afterstep civilizáltabb változata, 
ami a gyakorlatban annyit tesz, hogy meg lett fejelve egy 
grafikus beállítási modullal. Ennek segítségével már szinte 
gyerekjáték a beüzemelése. Egyedül a gombpanel kezelése 
érdekes. Ez ugyanis úgy működik, hogy ha egy grafikus 
programot futtatunk, ,ikonja" egy gomb formájában jelenik 
meg az asztalon, amit azután az egérrel , odaragasztha- 
tunk" a gombsorhoz. A legtöbb elem módosítható a meg- 
szokott gyorsmenükön keresztül (jobb egér kattintás). Az 
eddigiekhez képest új szolgáltatás, hogy kis programocská- 
kat, úgynevezett kisalkalmazásokat (appleteket) ragasztha- 
tunk az asztalra, ezek ugyanolyan megjelenési tulajdonsá- 
gokkal bírnak, mint a gombpanel, de attól külön is elhe- 
lyezkedhetnek. Ilyen kis appletek lehetnek például az 
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5. kép Az lceWM ablakkezelő 


Xmms-vezérlő, hangerőszabályzó, hálózati forgalom kijelző, 
processzor-terheltség (system load) jelző stb. Linux alatt 
egyébként minden ilyen kis programocskát, amely arra hi- 
vatott, hogy folyamatosan tájékoztassa a felhasználót, vagy 
éppen beavatkozási felületet nyújtson minden helyzetben, 
kisalkalmazásoknak vagy appleteknek nevezzük. 
Végkövetkeztetésként elmondhatjuk, hogy ez valóban 
igazán használható ablakkezelő. Egyetlen hiányossága 
talán, hogy nem kaphatunk állandó adatot arra nézve, 
hogy mely programjaink vannak elindítva, ugyanis nincs 
tálca, amelyen megjelennének az egyes programokat jel- 
képező gombok. 


IceWWM 


Ez az első olyan ablakkezelő a sorban, amely kísértetiesen 
hasonlít a Windowsra. Van benne Start gomb, van Start 
menü, van tálca és van hely az ikonoknak a tálca jobb szé- 
lén. Az asztalra történő ikonrakosgatás még e programban 
is bajos, de nem is ez a lényeg. Felépítését tekintve sokkal 
egyszerűbb, mint például a WindowMaker, akár fapado- 
sabbnak is tűnhet (nemcsak tűnik, de így is van), viszont 
azok számára rendkívül hatékony lehet, akik már jól meg- 
szokták a redmondi operációs rendszer nyújtotta grafikus 
szolgáltatásokat. Mivel maga az ablakkezelő is elég egysze- 
rű, ezért ne lepődjünk meg, ha minden apró kis jellemzőt 
be tudunk állítani grafikus felületről. Egyetlen ablakba lett 
minden bezsúfolva, amelyben a jobb oldalon lévő listából 
választhatjuk ki a beállítandó elemek körét, s a jobb oldalon 
megjelenő panelen végezhetjük a testreszabást. Sebességé- 
ben nem tudtam különbséget tenni az előzőekhez képest, 
mindegyik egyformán gyors. 


Xfce4 


Következzék egy kicsit nagyobb ugrás az előzőekhez ké- 
pest, ugyanis ez egy sokkal fejlettebb grafikus környezet, 
mint az előzőek. Azért nem mondom, hogy ablakkezelő, 
mert annál kicsit több. Megjegyzem, minden eddig tárgyalt 
,ablakkezelő" túlmutatott az egyszerű ablakkezelésen, 
ugyanis nemcsak az alkalmazásokat helyezte ablakba, ha- 
nem a hátteret is adta, azon egy menüt, és szinte mind- 


egyik tartalmazott gombpanelt is. Ezek mind az ablakkezelő 
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5. kép Xfce4 — visszafogott elegancia 


szolgáltatási színvonalát emelik. Számos esetben azonban 
még ezen is túlmutató szolgáltatások jelennek meg, s ezál- 
tal a hagyományos ablakkezelőkhöz képest többletet nyújtó 
alkalmazásokat szokták munkakörnyezetnek nevezni. Ilyen 
különleges szolgáltatás általában a munkamenet kezelése 

(a használat elejétől végéig vezérelve vagyunk, kilépéskor 
sorban bezáródnak a megnyitott programok), asztalkezelés 
(ikonok, menük), tálca használata, egységes keretrendszer, 
egyéb hozzátartozó programok (pl.: fájlböngésző), azt is 
mondhatnánk, hogy valójában egy feladat köré csoportosí- 
tott programok gyűjteményei. 

Nos, e munkakörnyezetek közé sorolja magát a GIK2-re 
épülő Xfce4 is. Megjelenését tekintve inkább a nagyokra ha- 
sonlít, de elég sok vonást örökölt a klasszikus ablakkezelők- 
től. Például, hogy a gyombpanel (button bar) külön áll a tál- 
cától és az ikondoboztól. Ez azonban kellően intelligens 
módon megoldott, ugyanis a gyombpanelre egyedül a tálcát 
nem lehet ráültetni, ezenkívül minden kényelmes szolgálta- 
tást igénybe vehetünk. Rátehetjük a munkafelületek közötti 
tájékozódást segítő lapozót, appleteket aggathatunk rá, egy- 
szóval igen kényelmessé alakíthatjuk. Itt is igaz, hogy min- 
den beállítható grafikus felületről, és a GIK 2.0-snak kö- 
szönhetően egy rendkívül igényes, végletekig testreszab- 
ható grafikus elemkészlettel gazdálkodhatunk. Az asztalon 
egy gyorsmenü is elérhető, amely azonban alapértelmezet- 
ten nem bukkan elő. Ehhez meg kell keresnünk a leírásban 
található XML példatfájlt, s ezt kell a saját könyvtárunkba 
másolni, esetleg kedvünk szerint átalakítani. (Ikonokat itt 
sem rakhatunk az asztalra.) A gombpanelen nincs ugyan 
Start menü, de gyakorlatilag öt perc alatt legyárthatunk 
egyet — hozzáadva a leggyakrabban használt programokat. 
Azokat, amelyeket nem adtunk hozzá, könnyedén elindít- 
hatjuk a futtatás panelen, amely az ALT-t-F2 billentyűkombi- 
nációval csalogatható elő. Ezzel nem ér véget a szolgáltatá- 
sok sora, melyek nagy része feltérképezhető az Xfce4 
beállítópaneljén, amin az egyes rendszerelemeket külön- 
külön testreszabhatjuk. 

Bátran állíthatom, hogy ez a munkakörnyezet nagyon haté- 
kony eszköz a mindennapok során: kellően egyszerű, ugyan- 
akkor minden megszokott lehetőség fejlett formában érhető 
el rajta keresztül. Ezenkívül igényes, sőt grafikáját tekintve 
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a legigényesebb , fapados", ám ezért az igényességért némi 
fizetség jár, méghozzá processzoridő formájában. De ne ijed- 
jünk meg, sokkal-sokkal gyorsabb, mint mondjuk a Cnome2, 
vagy a KDE, s a mindennapokban sem nyújt kevesebbet. 
Magam részéről csak dicsérni tudom ezt az alkalmazást. 


Xpde 

Érdekes ablakkezelő, amely fő céljának azt tekinti, hogy 
a Windows XP munkafelületének tökéletes mása legyen 
mind külcsín, mind működés tekintetében. Működés 
közben még nem próbáltam ki, mivel jelenleg a kevésbé 
üzembiztos állapotáról tanúskodó 0.5-ös változatszá- 
mot viseli. Ilyenkor még nem érdemes szenvedni vele, 
ugyanis a sok programhiba elveheti a kedvünket az 
egésztől. Ennek ellenére alaposan szétnéztem a honlap- 
jukon (2 http:/www.xpde.com), amelyen egész ígéretes 
képernyőképek találhatók. 


Több ablakkezelő egyetlen rendszeren? 

Bizonyára sokakban megfogalmazódott a kérdés: vajon 
megoldható-e az, hogy valaki több ablakkezelőt is használ- 
jon? A válasz természetesen: igen, előbb azonban nézzük 
meg, hogy ez miért lehet fontos. Egyrészt az átállást végző 
felhasználó gyakran szeret visszatérni a régi grafikus kör- 
nyezetbe még ezt-azt beállítani, vagy valamit lelesni, más- 
részt előfordulhat, hogy a sok-sok beállítási lehetőséget kí- 
náló, ámde igen lassú KDE-t használjuk arra, ha valami kü- 
lönlegeset szeretnénk átállítani, ugyanakkor az a célunk, 
hogy a mindennapi munkánkban egy egyszerűbb, gyor- 
sabb ablakkezelőt vehessünk igénybe. Ilyen, több grafikus 
felületet támogató rendszert akár kézzel is karbantartha- 
tunk, de a legegyszerűbb megoldás mégis az, ha segítségül 
hívunk valamilyen munkafelület-vezérlőt (desktop 
manager), amely arra hivatott, hogy az X-kiszolgáló elindí- 
tása után ablakkezelő helyett elindulva csatlakozzon a ki- 
szolgálóhoz. Ezekkel szokás megoldani a grafikus bejelent- 
kezést. Ha tehát a gépet elindítva alapértelmezetten indul 
a grafikus felület, s mi lehetőséget kapunk a bejelentkezés- 
re, akkor épp egy ilyen munkafelület-vezérlőt látunk ma- 
gunk előtt. Némelyikük további szolgáltatásként támogatja 
a különböző ablakkezelők használatát. Ez a gyakorlatban 
annyit jelent, hogy a bejelentkezés után az általunk kért 
munkafelületet indítja. Mi tehát a bejelentkezéskor kérhet- 
jük tőle, hogy az épp használni kívánt környezetet indítsa 
el, ezáltal máris megoldódott a különböző munkakörnyeze- 
tek kezelésének gondja. 

Most aztán valóban semmi sem állhatja olvasóink útját, sza- 
badon kipróbálhatják az összes fapados ablakkezelőt anél- 
kül, hogy közben , tönkretennék" a rendszerüket. Javaslom 
is mindenkinek, hogy próbálja ki mindegyik neki tetsző ab- 
lakkezelőt, hogy utána a saját meggyőződése alapján vá- 
laszthasson, és szegény édesanyámat ne gyötörje csuklás, 
ha netán valaki csalódik valamelyik ablakkezelőben. 


Komáromi Zoltán 
(komiokiskapu.hu) 

23 éves, a BME hallgatója, mellette 
PHP-programozóként dolgozik. 
Kedvenc területe a multimédia. 
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A szinek és a Gimp 22. rész) 


Folytatódjék Gimpről szóló sorozatunk, melyben elmondom azt Is, hogyan 
tehetjük gyorsabbá egy-egy képen a mozgást, ha görgős egérrel rendelkezünk. 


eltételezem, hogy X-kiszolgálónk tud a görgő létezé- 
séről és a kezelése is be van állítva (ZAxi sMapping be- 
jegyzés az X-kiszolgáló beállításaiban). Amennyiben 

e feltétel adott, a kép nagyítása a SHIFT billentyű nyomva tar- 
tása közben az egérgörgő mozgatásával változtatható meg. 

A függőleges görgetés a görgő használatával billentyűlenyo- 
más nélkül is megvalósítható, míg a kép vízszintes görgetése 
a CTRL billentyű és az egérgörgő segítségével oldható meg. 
Meg kell említenem, hogy sorozatunk előző részében a kije- 
lölések terén kissé megtréfálta olvasóimat a nyomda ördöge 
és meglepődve tapasztalhatták, hogy ha a kijelölt területből 
szeretnének elvenni, a SHIFT billentyűt lenyomva kell tarta- 
ni. Egyrészt ez minden Gimpben így működik, tehát a to- 
vábbiakban javaslom e tapasztalat gyakorlati alkalmazását. 
Másrészt viszont az ember játszva tanul. 





színkezelés 

Most azt szeretném bemutatni, hogy mire képes a Gimp 

a színkezelés területén, vagyis milyen műveleteket tudunk 
végezni a színekkel egy adott képen. Például megtudhatjuk, 
hogyan lehet túlexponált fényképeinket kicsit sötétebbé va- 
rázsolni, miként lehet kicsit élénkebbé tenni a fényképek szí- 
neit, és az így elkészített képeinket hogyan tudjuk felhasz- 
nálni leendő játékunkban is. Az alábbiakban főként a jobb 
egérgombbal megjeleníthető menü Kép (Image) menüpont- 
jával és a Színek (Colors) almenüjével fogunk foglalkozni. 

A jobb egérgomb hatására előbukkanó menüből válasszuk 
ki az Kép/Színek (Image/Colors) menüpontokat, és ebben 

a menüben kezdjük is el az ismerkedést a Színegyensúly 
(Color Balance) ponttal. Itt tudjuk beállítani, hogy az adott 
képen egy-egy meghatározott alapszín mennyire legyen 
túlsúlyban. A három vízszintes csúszkával adhatjuk meg 

a színek arányát, míg az alattuk található választómezőkkel 
adhatjuk a Gimp tudtára, mely színárnyalatokkal szeret- 
nénk foglalkozni. Azt, hogy mely színek tartoznak egy-egy 
kategóriába, a program a HSV színtérben a vCalue) érték 
alapján határozza meg. Ha a csúszkák beállítása közben 

a Preview kapcsoló be van kapcsolva, rögtön láthatjuk is 

a módosítások eredményét. Megjegyzem, hogy ez a kap- 
csoló más beállításoknál is előbukkan, így az itt leírtakat az 
adott helyzetben is érvényesnek kell tekinteni. 

Szintén a színegyensúlyra vonatkozik az Kép-/Színek-/ 
Szinezet-telítettség, de a beállításmódja kicsit eltér az előző- 
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1. kép A fakó kiinduló kép 2. kép Levél élénk színekkel 


ektől. Ennél a szolgáltatásnál a színeket közvetlenül a HSV 
térben megszokott értékekkel módosíthatjuk. A szokásos 
világosság-kontraszt módosítás az Image-/Colors-/ 
Brightness-Contrast menüpontok kiválasztásával lehetséges. 
Kicsit érdekesebb hatásokat érhetünk el a Küszöbszint 
(Threshold) szolgáltatással, ugyanis itt alakíthatjuk fekete-fe- 
hérré a képeket. Érdemes az ismerkedés során kicsit kísérle- 
tezgetni a beállításokkal, ehhez kezdetben elegendő annyit 
tudnunk, hogy az egérrel kijelölt világosságszinteket a prog- 
ram fehérnek fogja venni, míg az ezen a tartományon kívül 
eső színek feketévé változnak a beállítás hatására. 

A Szintek (Levels...) művelettel olyan, a gyakorlatban is 
gyakran előforduló feladatokat oldhatunk meg, mint az 

1. képen látható fénykép , feljavítása". A kép egy olyan leve- 
let ábrázol, aminek szinte csak világos színei vannak, vagyis 
a kép fakónak tűnik. Az eredeti kép hisztogramját ábrázol- 
va láthatjuk, hogy körülbelül a 61-es világosságérték alatt 
nincsenek képpontok. Ezzel a beállítóablakkal elérhetjük, 
hogy a 61-255 értékeket a program képezze le a teljes vilá- 
gosságtartományra, ezzel a 2. képen látható, élénk színű ké- 
pet sikerül előállítani. lermészetesen a meghatározott tarto- 
mányok nemcsak a példánkban szereplők lehetnek, hanem 
mindig a kiindulási képhez kell igazítani őket, és a kívánt 
eredményképpel szemben támasztott igények határozzák 
meg, milyen kimeneti tartományt kell beállítanunk. A beál- 
lításokra szolgáló párbeszédablakban a hisztogram alatti 
tartománybeállító csúszka adja a bemeneti tartományt, míg 
az alsó a kimenetet határozza meg. 

A Görbék (Curves) menüpont kiválasztásával szintén a be- 
meneti szinteket rendelhetjük adott kimeneti tartományok- 
hoz, és meghatározhatjuk, hogy a megrajzolt görbék mely 





3. kép Elcsúfított színek — Stretch Contrast 


színcsatornához tartozzanak. A párbeszédablak tetején lát- 
ható lenyíló listában választhatjuk ki a megfelelő csatornát, 
ez alapértelmezetten a világosságérték lesz. A kétdimenziós 
koordinátarendszer függőleges tengelyén találjuk a beme- 
neti szinteket, ezekhez a vízszintes tengelyen lévő értékek 
fognak tartozni a beállítás alkalmazása után. Ilermészetesen 
a beállításokat el is menthetjük, később pedig a megfelelő 
gomb használatával betölthetjük. 

Az eddig tárgyalt menüben a következő pontok egészen 
egyértelműen mutatják hatásukat. A Telítettlen (Desaturate) 
a színtelítettséget csökkenti, vagyis képünk szürke árnyala- 
tossá válik, míg az Invertálás (Invert) menüpont kiválasztá- 
sával a kép színeit invertálhatjuk. Például ezzel a hatással 
elérhetjük, hogy a régebben készült és előhívott fényképe- 
inket, megfelelő színekkel jelenítsük meg. A negatívokat 
képbeolvasó eszközzel (megfelelő feltét alkalmazásával) di- 
gitalizáljuk, majd a színeket ellentétükre változtatva a pozi- 
tív képhez jutunk. 

A Poszter (Posterize) szűrő sem igényel túl sok magyaráza- 
tot, ugyanis azzal érünk el poszterszerű hatást, hogy a ha- 
sonló színű képpontokat azonos színűre cseréljük. A szűrő 
beállításainál adható meg, hogy a program mennyi színnel 
próbálja közelíteni az eredeti képet. Megjegyzem, hogy en- 
nek az eljárásnak finomabb változatait (statisztikai számítá- 
sokkal, intelligens területfelosztással) komoly alkalmazási 
területeken is viszontláthatjuk, például a gépi látás vagy az 
orvosi diagnosztika terén. 

Miután ezekkel a szolgáltatásokkal megismerkedtünk, szót 
kell ejtenem néhány önműködő megoldásról is, amelyeket 

a képek minőségének javításakor használhatunk. A Gimp 
önműködően képes kiegyenlíteni egy adott kép vagy terület 
hisztogramját, ezzel elvileg elérhetjük, hogy egy alul- vagy 
túlexponált képet kontrasztosabbá tegyünk. Én ugyan nem 
sok képen alkalmaztam a kiegyenlítést, de az általam kivá- 
lasztott képeken (akár természetes fényképről készült, akár 
számítógéppel előállított képről volt szó) sokkal jobb ered- 
ményt értem el a Színjavítás (Color Enhance) művelettel, mint 
a Kiegyenlítés (Egualize) menüpont alkalmazásával. A Color 
Enhance oly módon változtatja a színeket, hogy a kép átlagos 
világossága nem változik, a hisztogram ugyanolyan marad, 
vagyis ugyanolyan arányban sötétíti a világos színeket, mint 
amilyen arányban a sötétebbeket világosabbá teszi. 
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A Normalizálás (Normalize) önműködő művelet hatására 

a képek részletei jobban előtűnnek a ,semmiből", hiszen ez 
a szűrő a normális Gauss-eloszlású görbéhez próbálja köze- 
líteni a kép hisztogramját. Sokat beszélek itt a hisztogram- 
ról, azonban lehet, hogy szükséges megvilágítanom, miről 
is van szó. Lássuk meghatározásszerűen: , hisztogramnak 
nevezzük egy kép világosságértékei eloszlásának grafikus 
ábrázolását." Érthetőbben fogalmazva, a vízszintes tenge- 
lyen találjuk a világosságértékeket, melyekhez a függőleges 
tengelyen egy gyakorisági érték tartozik. Kiszámítását oly 
módon végezhetjük el, hogy összeszámoljuk a képen talál- 
ható különböző értékeket, majd e számokat elosztjuk az 
összes képpontok számával. Így egy grafikont készíthe- 
tünk, ez mutatja meg, hogy az egyes értékek milyen arány- 
ban szerepelnek a képen. 

Hátramaradt még két önműködő művelet a színekkel kap- 
csolatban: az egyik a Kontraszt nyújtása (Stretch Contrast), 
amellyel a világosságértékeket húzhatjuk szét a teljes értel- 
mezési tartományra (például 24-bites képnél 0...255-re), 
ennek segítségével kontrasztosabb képet állíthatunk elő. 

A másik pedig e művelet olyan változata, amely a HSV szín- 
térben dolgozik s hatásában lényeges különbséget látha- 
tunk. Szemléltetésül lássuk a (3. képet), ami eredetileg sötét 
volt és a rajta lévő test szürke színárnyalatokban ,pompá- 
zott". A képen a Stretch Contrast művelet eredményét lát- 
hatjuk, melyen jól megfigyelhető, hogy bár jobban kivehető 
az alakzat a kontraszt változásának köszönhetően, de elve- 
szítette eredeti színét. Ugyanezen a kiinduló képen a HSV 
feszítés (Stretch HSV) műveletet végrehajtva a tárgy megőr- 
Zi eredeti színét, és úgyszintén jobban megkülönböztethető 
lesz a környezetétől. 

Érdekes és kísérletezésre csábító lehetőség a Colormap 
Rotation menüpont hatására előkerülő párbeszédablak. 

A lehetőségek elég sokrétűek, röviden összefoglalva annyit 
tudnék mondani róla, hogy egy képen található adott szín- 
tartományt egy másik, meghatározott tartománnyá alakít- 
hatunk át. A színeket tehát felcserélhetjük, megadva, hogy 
mely színek milyenné változzanak. A párbeszédablak Misc 
lapján pedig meghatározhatjuk, hogy a program mit kezd- 
jen a szürke színekkel, és mely színeket tekintse szürkének. 
A műveletek alkalmazásával például elérhetjük, hogy a kék 
égboltot akár sárgává változtassuk, ezen kívül még számos 
különleges hatást valósíthatunk meg. 


Utolsó simítások 
Utoljára maradt az utolsó menüpont: a Filter Pack párbe- 
szédablakban felhasználóbarát módon tudjuk változtatni 
a képnek azokat a tulajdonságait, amelyeket már korábban 
megismertünk. A Hue-Saturation, a Brightness-Contrast és 
a Color Balance műveletek alkalmazása során élőben láthat- 
juk az egyes változtatások után felmerülő lehetőségeket. 
Nagyon alkalmas gyakorlásra, ha ugyanis egy-egy kép ese- 
tében nem vagyunk teljesen biztosak a műveletek megfele- 
lő sorrendjében, ezekkel a párbeszédablakokkal közvetlen 
visszacsatolást kaphatunk, és segítségükkel könnyebben el- 
igazodhatunk a sok érték, illetve módosítás útvesztőjében. 
Kellemes ismerkedést és hasznos időtöltést kívánok olvasó- 
imnak, és a következő számban folytatom e nagy tudású 
program bemutatását. 

Fábián Zoltán 
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LinuxBIOS négy év alatt 


A LinuxBIOS több mint egy egyszerű megoldás, ami linuxos számítógépek 
néhány másodperc alatti elindítására szolgál. A Linux-telepek új programjai 
szintén kínálnak tartalék üzemmódot, amellyel megmenthető a rendszer, 
ha BIOS-frissítés közben megy el az áram. 


LinuxBIOS egy olyan GFL alá tartozó program, 
A amely helyettesíti a legtöbb számítógép BIOS-át, 

beleértve az AMD64, x86, Alpha és PowerPC rend- 
szereket. A LinuxBIOS gyártófüggetlen, kiépítés-semleges 
BIOS, amelynek több mint 95 százaléka C-ben íródott. 
A LinuxBIOS négy éves. A világ legnagyobb telepei közül 
néhány LinuxBIOS-t használ, hasonlóképpen a világ legki- 
sebb beágyazott rendszereihez. Mind a World Irade Center 
romjai közt túlélők után kutató, mind az Afganisztánban és 
Irakban használt robotokban LinuxBIOS-t alkalmaztak. 
A LinuxBIOS-t sok gyártó támogatja, például az AMD és 
a Ivan is. Ma már lehet LinuxBIOS-szal is ellátott alaplapot 
rendelni a Tyantől. Írásunkban bemutatjuk a LinuxBIOS 
alapvető felépítését, az eredetét és azt, hogy miként érte el 
jelenlegi fejlettségi szintjét. Szót ejtünk még az őt támogató 
felületekről és azokról a tapasztalatokról, amelyeket akkor 
szereztünk, amikor megpróbáltuk társítani a GPL projektet 
és a gyártók legféltettebb titkait. 


A LinuxBIOS szerkezete 

Mielőtt belemerülnénk a LinuxBIOS szerkezetének taglalá- 
sába, vessünk egy gyors pillantást a korszerű PC-k felépíté- 
sére. A PC egy halom lapkából áll — beleértve a processzort, 

a grafikus és a billentyűzetvezérlőt -—, amelyek buszokkal 
vannak egymáshoz kapcsolva. A busz egy vagy több veze- 
ték, amellyel két vagy több lapka van összekötve. Néhány 
busznak két vezetéke létezik, egy jel és egy föld, míg más 
buszoknak tíz vagy akár több száz is lehet. Az 1. ábrán egy 
nagyon egyszerűsített diagram látható. A különböző típusú 
buszok nem kapcsolhatók közvetlenül egymáshoz, ezért hi- 
daknak nevezett lapkák látják el ezt a feladatot. Az első busz 
az előoldali busz (Front-Side Bus, FSB) és a legtöbb PC-n ez 
köti össze a processzorokat egymással (amennyiben több is 
van), illetve az északi híddal. Az északi híd köti össze a CPU- 
(ka)t a memóriabusszal és a PCI busszal. Az ábránkon csak 
létezik. Például az AMD Opteron minden processzorhoz egy 
északi hidat használ, és az FSB minden Opteron processzort 
csak a saját északi hídjával köt össze. Más szóval, az Opteron 
rendszerben nincsen megosztott FSB. Mindazonáltal az észa- 
ki híd azonosítható eszköz az Opteron lapkakészletben. 
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1. ábra Az alap-PC felépítésének egyszerűsített képe. A hidak, lapkák, 
amelyek a buszokat egymáshoz kapcsolják 


A sorban a déli híd a következő, amely szinte mindig a 0-dik 
PCI buszon ül. A déli híd feladata a PCI busz és a PC 1981-es 
megjelenése óta meglévő, úgynevezett örökölt eszközök 
(például soros kapu) közötti kapcsolat megteremtése. Szin- 
tén a déli híd hajtja a BIOS flash részét. 

Mikor a PC-t bekapcsoljuk vagy újraindítjuk, a CPU olvasni 
kezd egy ismert címről, ami hagyományosan a memória te- 
teje (Iop of Memory —- TOM) mínusz 16 bájt. Az eredeti 8086 
esetében ez a cím a Oxffff0, újabb PC-ken pedig Oxfffffff0. 
Ezt az olvasási utasítást támogatnia kell az eszközöknek még 
a beállítások elvégzése előtt, ugyanis egy csomó eszköznek 
hadrendbe kell állnia az első utasítás beolvasásához. 
Mindazonáltal bekapcsolása után a PC még nincs felkészül- 
ve a C-kódra, pusztán assemblyt tud futtatni. Az alaplapot 
több lépésben kell feléleszteni. Ennek folyományaként 

a LinuxBIOS-nak egy sorozat behúzója (bootstrap) van, 
ezek akkor kerülnek sorra, amikor újabb CPU-erőforrások 
lépnek működésbe. Minden behúzó feltételezi, hogy bizo- 
nyos erőforrások engedélyezettek és a gépnek egy jól meg- 
határozott erőforráskészlet áll rendelkezésre. 


Ezek a LinuxBIOS szakaszok a következők: 

e Az első 10 vagy 15 utasítás, amely engedélyezi a pro- 
cesszort, minimális virtuális memóriakapacitást (32 bites 
címekkel), valamint egyéb erőforrásokat, amelyek a me- 
mória bekapcsolásához szükségesek (mint pl.: az I2C 
busz). Ezenkívül beállítja a processzor belső állapotát, 
eközben egy csomó dolgot kitakarít, például az utasítás- 
csővezetéket. 

e . Memóriaindító kód, amelyhez egy tiszta és egészséges 
processzor, valamint egy működő I2C busz szükséges 
a memória jellemzőinek lekérdezéséhez. 

e . Programkód, amely az eredetileg C-ben írt objektumkó- 
dot (object code) a flashból a memóriába tölti. Az objek- 
tum kód igény szerint lehet tömörített is. 

e . Programkód, amely akkor fut, ha a memória már műkö- 
dik. Ez a kód végigpásztázza a gép erőforrásait és elin- 
dítja őket. 

e .  Fgy vagy több olyan , rakomány", amely elvégzi a végső 
beállítás feladatát és elindít egy operációs rendszert. 


Mindezek a szakaszok a 2. ábrán láthatók. 

A LinuxBIOS támogat egy választható tartalék BIOS-t, 

arra az esetre, ha az eredeti BIOS-szal valami baj történne. 
A tartalék támogatása a BIOS-ba fordításakor kerül bele. 

A kiegészítő kód ellenőrzi a CMOS jelzőt is és felismeri, ha 
a CMOS sérült, akár azért, mert az előző BIOS nem tudott 
rendesen elindulni, akár azért, mert a felhasználó a tartalék 
BIOS-szal akarja a rendszert indítani. A tartalék BIOS egy 
teljes LinuxBIOS-lenyomat (image), melynek képességei 
egyáltalán nincsenek korlátozva. 

A tartalék főleg felügyelet nélküli BIOS frissítésekkor hasz- 
nos. Képzeljünk el egy olyan esetet, amikor 1024 vagy még 
több csomóponton (node) BIOS-t kell frissíteni — mi történik, 
ha félúton elakadunk vele? A legtöbb rendszernél ilyenkor 
lesz egy nagyon drága papírnehezékünk. A LinuxBIOS-szal 
viszont egy egyszerű újraindítás után önműködően tartalék- 
módban indul a rendszer. 


A LinuxBI0S eredete és fejlődése 

A LinuxBIOS projektet a Los Alamos National Labben 
(LANL) kezdtem el, 1999 szeptemberében. Az ezt megelő- 
ző nyolc évben mindenféle telepet építettem, majd 1994- 
ben befejeztem az első PC-telepet. A BIOS mindvégig aka- 
dályozta a nagyobb telepek építését. 

1997-ben egy 144 csomópontos Cyclone-telepet raktam 
össze a Sarnoff Corporationnél. Kísérletképpen csak 

16 csomópontban volt videokártya. A kísérlet nem sike- 
rült, mert a hagyományos BIOS-szal felszerelt PC-k egy- 
szerűen túl megbízhatatlanok ahhoz, hogy csak úgy kive- 
gyük a videokártyát, mivel a feladat megoldásához fel- 
használói beavatkozás szükséges. Világossá vált, hogy ha 
nagyobb telepeket szeretnénk létrehozni, meg kell oldani 
a BIOS nehézségeit. 

Meghatároztuk, hogy egy eszményi PC telepcsomópont- 
nak a következőket kell tudnia: az operációs rendszert köz- 
vetlenül indítja valamilyen nem felejtő RAM-ból, beállítja 
az összes hálózati csatolót, de nem állít be más eszközt, 
kapcsolódik egy vezérlő csomóponthoz - bármelyik mű- 
ködő hálózati csatolóját használva -, s csak vele együtt 
végez műveleteket. 
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Egy magáncég azonban nem a megfelelő helyszín az ilyen 
jellegű munkához, ezért ott soha nem jutottunk tovább az 
álmodozásnál. 

Miután a LANL-hoz kerültem, lehetőségem nyílt tovább- 
dolgozni ezen az ötleten. Számos technológiai irányvonal 
fejlődése sokkal jobb évvé tette az 1999-et (a 97-esnél). 
Ekkor jelentek meg az első 1 MB flashmemóriával szerelt 
alaplapok, s a PCI busz teljesen felváltotta a régebbi EISA és 
ISA buszokat. Szintén lényeges, hogy ekkorra a Linux sok- 
kal több beállítást volt képes elvégezni, amit jól példáz az 
SGI Visual Workstation, aminek egyáltalán nincs is BIOS-a. 
Tisztán látszott, hogy ha a Linuxot be tudnánk tenni 

a BIOS-ba, azzal elérnénk célunkat. A Linux sokkal jobban 
el tudná végezni az eszközök üzemeltetését, mint bárme- 
lyik BIOS, amit eddig láttunk. Egyedül egy hardveres behú- 
zóra volt szükségünk, ami a Linuxot a flashból a memóriába 
tölti, a többit már maga a Linux végzi el. Innentől kezdve 

a mottónk: , Bízzuk a Linuxra!" lett. 

Mielőtt a LinuxBIOS projekt teljes gőzzel beindult volna, 
meg kellett győződnünk arról, hogy a Linux használható 
behúzóként, vagyis a Linux képes Linuxot indítani. 1999 
decemberére a LOBOS-szal (Linux OS Boots 05) bemutat- 
tunk egy Linux-rendszert indító Linuxot. 

Bármely munka elvégzésének legkönnyebb módja a nyílt 
forrás (Open Source) világban, ha megengedjük, hogy más 
végezze el helyettünk, ezért a LinuxBIOS következő lépése 
az volt, hogy kerestünk egy kész programot. James Hendricks 
és Dale Webster már készített ilyen rendszert az OpenBIOS 
projekt keretében. Az OpenBIOS forrás felhasználásával öt 
szabadnap alatt írtak és építettek egy próbarendszert az Intel 
L330GX- alaplapjainkra, amely újraindítás — nem bekapcso- 
lás — után képes volt elindítani a rendszert. Egy kikapcsolt 
gép indításának megoldása újabb öt hónapba tellett volna, 
de eddig ez nem rossz teljesítmény az öt naphoz képest. 
Korán felismertük, hogy nem az assembly a LinuxBIOS 
jövője. Az OpenBIOS-ban rengeteg assembly volt, egy bo- 
nyolult építői (build) szerkezettel. Kis közösségünk nekilá- 
tott jobb alapot keresni a LinuxBIOS-hoz. Feff Garzik talált 
egy új BIOS-t és megtudta, hogy a készítő SIPC hajlandó 
nyílt forrásúvá tenni. Az SIPC BIOS lett az alapkódja az új 
LinuxBIOS-nak. Az SIPC-kód alapvető átszervezést igé- 
nyelt, hogy többféle alaplapot és lapkakészletet támogas- 
son, de jó kiindulási pontot nyújtott. 

A következő hat hónapot azzal töltöttük, hogy néhány felü- 
leten futtathatóvá tettük a LinuxBIOS-t. Az első nem grafi- 
kus felület egy Intel L440GX-- alaplap volt, amit egy 515630 
alaplap követett. A SiIS esetében maga a gyártó is segédke- 
zet nyújtott, műszaki leírást, tervrajzokat, programkódot, 
technikai támogatást adott és célul tűzte ki, hogy a Linux- 
BIOS fusson a felületén. 

Megtanultuk, hogy a Linux mit képes és mit nem képes 
megtenni. Ebben az időben a 2.2-es rendszermaggal dol- 
goztunk. Rájöttünk, hogy a Linux képtelen egy PCI buszt 

a semmiből beállítani, viszont a LinuxBIOS-nak képesnek 
kell lennie erre is. Sikerült kiemelnünk a PCI-kódot a Linux- 
ból és módosítások után közvetlenül felhasználni a Linux- 
BIOS-ban, miközben a valódi PCI-beállításhoz szükséges 
kiegészítéseket hozzáadtuk. Azt tapasztaltuk, hogy a Linux- 
BIOS olyan gyorsan jött fel, hogy az IDE-meghajtók nem 
pörögtek fel addig. Folytatjuk egy Linux-folt támogatását, 
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2. ábra A LinuxBIOS szakaszai 


ami ezt a gondot oldja meg. Mindezek és sok más feladat, 
néhány váratlan változtatást igényeltek a , Bízzuk a Linuxra!" 
szemléletben. 

A kilencedik hónapra volt egy LinuxBIOS-unk, mely két 
felületen is jól működött, jobbára C-ben készült, továbbá 
néhány vállalat érdeklődését sikerült felkeltenünk vele. 

A Via és az Acer leírást adott, ennek felhasználásával támo- 
gatni tudtuk az új lapkakészleteiket is. Azon a nyáron 
James Hendrick elkezdett dolgozni az SMP-támogatáson, 
,Bízzuk a Linuxra!" módban, így ez a támogatás Linux 
rendszermag-folt formájában és nem LinuxBIOS kiegészí- 
tésként jött létre. Egy ponton, a mi foltjaink segítségével, 

a Linux-mag egyprocesszorosként áll fel és a semmiből 
tudja engedélyezni a többi processzort — ez olyasmi, amit 
eddig csak a BIOS-ok tudtak megtenni. 

Azon a nyáron a Linux NetworX, és nagy szerencsénkre, 
Eric Biederman is csatlakozott hozzánk, hogy kivegye részét 
az erőfeszítésekből. Fric legfontosabb korai munkája az 
Alphára átültetés volt, emellett jelentősen megtisztította 

a memóriaindító kódot. Együttműködésünk mind a mai na- 
pig tart, a Linux NetworX a LinuxBIOS alapú rendszerek 
legnagyobb viszonteladója, Eric pedig besegít a LinuxBIOS 
2-es változatának tervezésébe és létrehozásába. 

Ősszel előadásokat tartottunk az Atlanta Linux Showcase 
2000-en, ahol találkoztunk Steve James-szel a Linux Labstől. 
Ez a kapcsolat hozzásegített bennünket, hogy kevesebb 
mint egy hónap alatt megvalósítsuk álmunkat: építettünk 
egy 13 csomópontos, LinuxBIOS alapú telepet a Super- 
computing 2000-re. A telep teljes üzemi állapotát kb. 13 má- 
sodperc alatt volt képes elérni. 

2001-re a Linux NetworX befejezte az Alpha átültetést 

a DS10-re. Ekkor telepet építettünk 104 DS10-ből, és mind- 
egyiken LinuxBIOS futott. A DS10 sokkal lassabban indult, 
mint egy Pentium rendszer, ezért ennek a telepnek ötven 
vagy még több másodpercre volt szüksége az üzemkész ál- 
lapot elérésre, de ez a sebesség még mindig jócskán elvisel- 
hető volt. Találkoztunk olyan BIOS-okkal, amelyeknek csak 
a memóriapróbája tartott ennyi ideig. 

Az Alphára átültetés bebizonyította, hogy a LinuxBIOS hor- 
dozható. Nagyon kevés kódot kellett módosítani, és 64 bites 
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BIOS-ként vagy 32 bites BIOS-ként egyaránt jól működött. 
2001-re növeltük a fejlesztők számát (most 11-en dolgoz- 
nak) és folytattuk az átültetést még több felületre, ezek kö- 
zül a legutolsó az AMD Opteron volt. Mi a LinuxBIOS-t ki- 
zárólag telepekhez képzeltük el, de a nem telepként való 
felhasználás maga mögé szorítja a telepalkalmazások szá- 
mát. Úgy gondoltuk, hogy a Linux végez majd minden ne- 
héz feladatot, mostanra a LinuxBIOS egy csomó dolgot el- 
lát, beleértve az SMP-indítást is. Szerettük volna a , Linuxra 
bízni , de as AMD K7/ SMP eszköz kialakítása szükségessé 
tette, hogy az SMP indítás a BIOS-ban menjen végbe. 

Úgy gondoltuk, a gyártók be fognak szállni a munkába. 
Négy évig tartott, de most, a LinuxBIOS fejlesztésének ötö- 
dik évében a világ legnagyobb számítógépgyártói közül né- 
hánynak felkeltettük az érdeklődését. Egy kicsit derúlátób- 
bak voltunk a szükséges idő megbecsülésében. Amint egy 
gyártó látja a dolog üzleti oldalát, elkezd érdeklődni iránta. 
2003-ban legalább harmincmillió dollár értékben adtak el 
LinuxBIOS alapú rendszereket, míg ez a szám 2000-ben 
egymillió alatt maradt. 


Felületek 

A LinuxBIOS a felületek széles választékán fut. Ötven tá- 
mogatott alaplap van a forrásfában, de úgy találjuk, sok 
alaplap annyira egyforma, hogy az egyiken működő 
LinuxBIOS a másikon is menni fog. A cégek gyakran csak 
egy kódot készítenek, azt futtatják több alaplapon, csak ép- 
pen nem mondják el nekünk. 

A LinuxBIOS 64 bites és 32 bites processzorral egyaránt mű- 
ködik. A processzor-támogatás magában foglalja az Alpa, 
K83, K7, PowerPC, P4, PIII, PII, Cyrix(VIA), Geode (AMD), 
S5C520 (AMD) processzorokat. A lapkakészleteket fel sem 
lehet sorolni, annyian vannak, az alaplapokat pedig a legki- 
sebb PC/104-estől a legnagyobb K8-as méretig támogatja. 
Az IBM PPC 970-re való átültetés pedig éppen zajlik. 


Lapkakészlet-titkok 

Az első néhány évben a lapkakészlet-gyártóktól leggyak- 
rabban hallott mondat az volt: , Azt soha nem fogjuk el- 
mondani". Az , azt" a processzorra, lapkakészletre, alaplap- 
ra vonatkozó adatokat és kombinációikat takarja. E három 
rendszerösszetevő tervei, felépítésének adatai szigorúan Őr- 
zött titkok. Még ma is hihetetlennek tűnik, hogy akadnak 
olyan gyártók, akik lehetővé tették számunkra, hogy az ál- 
taluk rendelkezésre bocsátott titkos adatok segítségével lét- 
rehozzunk egy GPL alá tartozó BIOS-t. 

Hogyan sikerült ezeket az adatokat megszerezni? Egyszerű, 
a cégek nem karitatív intézmények, ha nem látnak benne 
üzletet, hogy megosszák velünk ezeket az adatokat, akkor 
nem fogják. Ha viszont látnak benne üzletet, akkor hajlan- 
dóak erre, gyakran meglepően gyorsan. 

Ahogyan mi látjuk, a sikerünknek két kulcseleme a verseny 
és a piac létrehozása volt. A versenynek köszönhetjük az 
alaplapok, lapkakészletek és processzorok széles választé- 
kát. Amint számottevő piac alakult ki, a gyártók igyekeztek 
bekerülni oda. 

A LANL-nál szerzett tapasztalatok tanulságosak. A LANL 
két utolsó nagy telep pályázati kiírása a LinuxBIOS alkal- 
mazását feltételként szabta. Ugyanitt a költségeket több 
mint 19 millió dollárban állapították meg. Azok a cégek, 


akik nem akartak részt vállalni a LinuxBIOS projektben, 
nem vehettek részt ezen a pályázaton, azoknak viszont, 
akik elég korán beszálltak a játékba, most minden lehetősé- 
gük megvolt a részvételre. Az előrelátás ebben az esetben 
versenyelőnyhöz juttatta őket. 


Összegzés 

A LinuxBIOS négy év alatt hosszú utat tett meg az ötlettől 

a gyártásig. LinuxBIOS-t használnak mindenféle eszközben 
a legnagyobb telepektől kezdve a kis próbaeszközökig, 
MP3-lejátszókig és hordozható telepekig. A LinuxBIOS lehe- 
tővé teszi, hogy ne PC eszközraktárként szolgáló rendszere- 
ket építsünk. A rendszereket hatékonnyá lehet tenni 
Linuxon, ennek következtében jóval egyszerűbbek lehetnek. 
A négy éves LinuxBIOS most a második változatnál tart, 
legalább hatféle processzorral, és több mint ötven alaplap- 
pal gyűjtött tapasztalat áll mögötte. Egyes esetekben akár 
napok alatt egy új rendszerhez lehet igazítani, ezt megelő- 
zően ez eredetileg hónapokig is eltartott. A LinuxBIOS ha- 
tása a számítástechnika világára csak most kezdődik. 


Köszönetnyilvánítás 

Sokan vettek részt a LinuxBIOS körüli munkákban, szinte le- 
hetetlen mindnyájukat felsorolni. Mindazonáltal néhány 
munkatársnak komoly szerepe volt abban, hogy a Linux- 
BIOS létrejött. Szeretném megemlíteni Stefan Reinauer-t és 
Jeff Garzik-ot, akik az SIPC BIOS projektet a SourceForge-on 
FreeBIOS-ként felállították. Nem maradhat ki a sorból Ollie 
Lho sem, aki sokat tett azért, hogy 2000-ben az első munkaál- 
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lomás-felületek működjenek. Steve James és a Linux Labs ve- 
lünk együtt dolgoztak, és 2000-ben bonyolították le az első 
LinuxBIOS-os telep szállítását. Greg Watson végezte a Power- 
PC átültetését, és Eric Biederman sokat tett azért, hogy az 
igazán nehéz felületeken is felálljanak és üzembiztosan mű- 
ködjenek, valamint a 2. változat munkálataiból is kivette 

a részét, mindkettejüket köszönet illeti ezért. 

Ez az írás a LAUR 03-8165 alatt lett kiadva. Ezt a kutatást 

a DOE Iudományos irodájának és a Los Alamos Computer 
Science Institute (ASCI — Számítástudományi Intézet) 
Mathematical Information and Computer Sciences (MICS — 
Matematikai Információ és Számítástudományok Program- 
ja) alapította. A Los Alamos National Laboratoryt (Los 
Alamos Nemzeti Laboratórium) a University of California 
(kaliforniai egyetem) üzemelteti, a National Nuclear 
Security Administration of the United States Department of 
Energyvel kötött W-7404-ENG-36 számú szerződés alapján. 


Linux Journal 2004. február, 118. szám 


Ronald G. Minnich 15 éve dolgozik a nagytelje- 
sítményű számítástechnika és telepek terüle- 
tén. Nemrég jött rá, hogy első telepeinek egyt- 
ke, egy 16 csomópontos SPARC-telep éppen 
egynegyed teljesítményét nyújtja egyik leg- 
újabb, 2048 processzoros telepének egyetlen 
processzoráénak. Az új telepének teljesítménye tízezerszere- 
se az első telepének. Ron 1976 óta dolgozik Unixszal, 1993 
óta Linuxszal, első PC telepét pedig 1994-ben építette. 
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Az XWindow távoli elérése (2. rész) 


A Unix világában szokványos feladat egy távoli gépet karakteres felületen 
keresztül elérni. Most az XDMCFP-vel folytatjuk. 


ddig csak egy-egy ablakot rajzoltattunk a helyi kép- 
ernyőre, viszont az X Display Manager Control 
Protocollal (XDMCP) teljes X-folyamatot (session) 
tudunk futtatni a távoli gépen, és a helyi képernyőn megje- 
leníteni. Ehhez engedélyeznünk kell a munkafelület-keze- 
lőnkben. Ha gdm-et használunk a /etc/gdm/gdm.conf-ban 

a következőknek kell szerepelnie: 


[xdmcp] 

Enable-true 

Port-177 

wil1]ing-/etc/gdm/Xxwilling 

Az Xwilling egy parancsfájl, amivel ha közvetett (indirect) 
módon kapcsolódunk, akkor a gépről adatokat írathatunk 
ki a tényleges csatlakozás előtt, például bejelentkezett fel- 
használókról, a kiszolgáló terheltségéről. 

Az otthoni gdm.conf fájlunk így nézzen ki: 


[servers] 
0-Terminal -guery munkagep.hu 


Ha nem használunk az otthoni gépen gdm-et, akkor így 
indítsuk az X-kiszolgálót: x -indirect munkagep.hu 
Esetleg a következőképpen: X -guery munkagep.hu 

A helyi hálózatban pedig ilyen módon: X -broadcast 

Ha az indirect kapcsoló hatására egy X-kiszolgálót választó 
képernyő jelenik meg, amelyben eldönthetjük, hogy melyik 
géphez csatlakozunk ténylegesen (például a willing parancs- 
fájl adatai alapján), közvetlenül a guery kapcsoló segítségével 
kapcsolódhatunk, a broadcast-tal pedig az elérhető leggyor- 
sabb X-kiszolgálóhoz csatlakozhatunk. Biztonsági megfonto- 
lásokból az XDMCP-t csak megbízható hálózaton használjuk, 
mert mindent titkosítás nélkül küld át a vezetéken. 


A VNC 


A VNC-vel (Virtal Network Computer) is lehetőségünk nyí- 
lik grafikus felület megjelenítésére a távoli gépen. Azonban 
ez az XDMCTF-től néhány fontos dologban eltér: az egyik, 
hogy akár Windowsról és Windowsra is működik, sőt mi 
több, böngészőn keresztül Java-ügyféllel is hozzá lehet kap- 
csolódni. A másik fontos eltérés, hogy ha megszakítjuk 

a kapcsolatot, a munkafolyamatunk továbbra is fut, ilyen 
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módon egy későbbi időpontban ugyanonnan folytathatjuk 

a munkánkat, ahol abbahagytuk. A harmadik különbség, 
hogy akár többen is nézhetik, dolgozhatnak ugyanazon 

a munkameneten. Ennek az eddigi kapcsolatokhoz képest az 
a hátránya, hogy nagyon magas szintű kapcsolatot hoz létre 
(bitmap tömörítés elvén működik), ezért nagyon leterheli 

a hálózatot. A TightV NC a VNC egy hatékonyabb változata, 
és együttműködik az egyszerű VNC-vel is, igaz ekkor 
lemondunk a gyorsításokról. Sajnos az eredeti VNC-vel Unix 
alatt csak egy újonnan indított X-kiszolgálót lehet kiajánlani, 
azaz a már elindított X-et nem. Ezen segít a xorfbserver és 
a KDE-s krfb, velük menet közben is ki lehet ajánlani 

a munkamenetet. Alkalmazásunk a következőképpen fest 

a távoli gépen: a vncserver vagy tightvncserver az új X- 
kiszolgálók indítására szolgál, az xorfbserver vagy a krfb 
pedig a már futó X-ek kiajánlására használatos. 

A helyi gépen pedig így néz ki: xtightvncviewer vagy 
xvncviewer vagy bármi más, ami képes VNC-kiszolgálóhoz 
kapcsolódni, számtalan ilyen létezik Gnome és KDE alatt, 
sőt létezik X nélküli változat is (di rectvnc). A VNC világá- 
ban hasonlóan lehet hivatkozni egy képernyőre, mint az X- 
nél ( Ckiszolgálónév: : Cképernyőszám- ), de nem ugyanaz 
a kettő, mivel nem is biztos, hogy X rejlik a VNC-kiszolgáló 
mögött. Mielőtt VNC -t használnánk, nézzük át a beállításait 
a /etc/onc.conf-ban. 


Egyéb hasznos programok 

A WiredX egy Java nyelven írt ingyenes X-kiszolgáló. Így akár 
nem Unix-környezetben is kihasználhatjuk az X protokoll 
továbbításának lehetőségét. Támogatja a XDMCFtt is, és akár 
rootwindow nélkül is futtatható, azaz csak a megnyitott alkal- 
mazások látszanak, nincs , asztal". Sajnos a magyar billentyű- 
zetkiosztást még nem támogatja. Az xtv alkalmazással pedig 
tévészerűen nézhetünk egy távoli X-et. 


Összegzés 

Az előző számban és a most bemutatásra kerülő progra- 
mokkal széles skálán használhatjuk a világ egyik legjobb és 
legátlátszóbb grafikus kiszolgálóját az Xwindow rendszert, 
remélem mindenki megtalálta a számára megfelelő kapcso- 
lódási módot a munkájához. 


Radics László (garaboncias(omailbox.hu) 


A magyar Linux: UHU - Irodai felhasználás (4.rész) 


Az ,ismert erdei körökben általánosan elterjedt nézet" szerint, a Linux alkalmatlan 
üzleti felhasználásra. Nos, ez az állítás valamikor talán igaz is volt, mára azonban 


cégek tízezrei cáfolnak rá. 


ára az irodai felhasználásnak gyakorlatilag nin- 
csen programbeli akadálya, az egyetlen nehézsé- 
get esetleg az integráció okozhatja. Az UHU erre 
a célra is megfelel, hiszen fejlesztői nemcsak az otthoni fel- 
használók számára akartak adni , kulcsrakész" rendszert, 
hanem a vállalkozásokra is gondoltak. 





Szövegszerkesztés és iroda 

A Sun által fejlesztett StarOffice forráskódjának fel- 
használásával indult, és azóta is töretlenül fejlődik az 
OpenOffice.org. Népszerűségéhez kétség sem férhet, hi- 
szen több felmérés szerint az OpenOffice.org (a további- 
akban OO.o) Windows alá készült változata még a nagy 
cégek vezetőit is elgondolkodtatta alkalmazásának szüksé- 
gességéről. Az OpenOffice.org igen jó példája annak, hogy 
a nyílt forrás közössége igenis képes olyan programot létre- 
hozni, amely komoly vállalati felhasználásra is megfelel, 
sőt a költséghatékonyság előnyeivel is felruházták. lermé- 
szetesen — az összes Linux-változattal együtt — az UHU is 
tartalmazza az OO.o 1.1-es változatát. 

Sok vád éri, hogy tudása nem akkora, mint a versenytárs 
kereskedelmi termékeké. Azt azonban ne feledjük el, hogy 
a mindennapi irodai feladatok a nagy tudású termékek ké- 
pességeinek mindössze pár százalékát igénylik. Személyes 
tapasztalatom szerint, az OO.o is többet tud, mint amit az 
átlagos irodai felhasználásmód megkövetel és igényel. (Ez 
a megállapítás azonban nem keverendő össze a szolgáltatá- 
sok eltérő nevéből és a menüpontok különböző elhelyezke- 
déséből adódó átállási kényelmetlenséggel. A kívánt felada- 
tot valószínűleg el tudjuk végezni az OO.o-gal, mindössze 
még nem áll rendelkezésünkre az a tapasztalat, hogy tud- 
juk miként.) Mindezt természetesen anyanyelvünkön, hi- 
szen a rendszer honosítva került az UHU-Linuxba, és 

a Myispellnek köszönhetően a helyesírás-ellenőrző is 

,tud magyarul". 

Ennél azonban sokkal többet tud a csomag, de ezt csak ak- 
kor tudjuk értékelni igazán, ha szükségünk van rá. Gondo- 
lok itt az OO.o rajzoló programjára, ami nem egy Gimp, de 
kellemes kis program, ráadásul azonnal , kézre áll" az Oo.o 
használata során. lovábbá kiválóan összedolgozik a prog- 
ramcsomag többi részével is. De figyelemre méltó a név- 
jegykártya- és címkekészítő programja is, amely viszont 
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igen jó minőségű címkéket, kártyákat tud létrehozni. ler- 
mészetesen mindkettőnek megvan a maga , tündére" , akire 
rábízhatjuk elképzeléseink megvalósításának főbb vonalait, 
a finomításokat úgyis kézzel fogjuk elvégezni. 

Ez az irodai csomag (ugyanis teljes értékű programcsomag- 
ról van szó) szövegszerkesztőt, képletszerkesztőt, 
bemutatókészítőt, rajzprogramot, valamint HIML-tervezőt 
is tartalmaz. lermészetesen mindegyikhez léteznek sablo- 
nok, képek és hangok is. Kezdő felhasználók valószínűleg 
örömmel veszik igénybe a beépített , varázslók" segítségét, 
egyébként az OO.o-ban , tündérnek" nevezik őket. Rendkí- 
vül hatékony segédeszközök, hiszen gyakorlatilag minden 
általános feladatra fel tudjuk használni őket, ráadásul 
üzembiztos és kényelmes környezetben. lermészetesen 
mindezt honosítva kapjuk kézhez. Mint minden korszerű 
program, az OO.o is teljesen XML-megfelelő, valamint 
,szót ért" több, akár kereskedelmi forgalomban kapható iro- 
dai csomag formátumaival is. Személyes tapasztalatom az, 
hogy a , külső" formátumokkal való együttműködés (az 
O0.o alapformátuma a .sxw) igen jó hatásfokú, még a zárt 
formátumok esetén is. Ez az állítás különösen akkor állja 
meg a helyét, ha a hétköznapi dokumentumok átjárhatósá- 
gáról beszélünk. Régi motorosok tudják, hogy minél egy- 
szerűbb a dokumentum, annál kisebb az esély a megfelelő- 
ségi gondok felbukkanására. Ez továbbra is igaz. Azt ne fe- 
ledjük el, hogy az OpenOffice.org semmivel sem ad többet, 
mint a kereskedelmi forgalomban kapható csomagok, a kü- 
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lönlegessége nem is ebben, hanem a nyílt forráskódjában, 
szabad felhasználásában, és a mindebből következő fejlő- 
dés ütemében nyilvánul meg. Mindez természetesen an- 
nak is köszönhető, hogy a Microsoft nem adta ki termékét 
Linuxra is. Bátran mondhatjuk tehát, hogy az OO.o remek 
programcsomag mind otthoni, mind általános irodai fel- 
használásra. 


A kicsik ís jelen vannak... 

Habár a legteljesebb megoldásnak az OO.o ígérkezik, azért 
ne feledkezzünk meg a kisebb méretű szövegszerkesztőkről 
sem. A KWord, a KDE rendszerhez készített KOffice irodai 
programcsomag része. Igaz ugyan, hogy a KOffice jóval ki- 
sebb tudású, mint az OO.o, azonban feladataink megoldá- 
sában ez is sokat segíthet, kiváltképp, ha nem túl összetett 
a feladat. Igazán kicsi, , lényegre törő" alkalmazásról van 
szó, amit mi sem bizonyít jobban, minthogy a KÖffice cso- 
mag mérete mindössze 12 MB. (Ez azonban senkit ne té- 
vesszen meg. Ne feledjük, hogy az Opera böngésző mérete 
is 3-5 MB között mozog, attól függően melyik csomagot 
töltjük le, ugyanakkor nagyon nagy tudású program.) Ebbe 
a 12 MB-ba belefért egy táblázatkezelő, szövegszerkesztő, 
bemutatókészítő, grafikonkészítő, képletszerkesztőt és jó 
néhány apró, ám annál hasznosabb alkalmazás is. 

Mint említettem egyszerűbb feladatokra, mondhatnám álta- 
lánosabb felhasználású vagy egyszerűbb irodai munkákra 
kiválóan használható. Meglepetést csak a grafikontervező 
hozott, ami méretéhez képest igencsak hasznos és kezes 
társnak bizonyult. Mint ismeretes (és ez a vád éri a legtöbb- 
ször az Oo.o-t, nem alaptalanul, mert sajnos így igaz) rend- 
kívül lassan töltődik be. Igaz, hogy utána remekül használ- 
ható, de bizony egy percig is eltarthat, mire teljesen betöltő- 
dik. Kisebb gépeken, amelyek kevesebb memóriával van- 
nak megáldva (128 MB vagy az alatt) jól jöhet egy használ- 
ható, de kisebb erőforrás-igényű irodai csomag. Erre a célra 
a KOffice kiválóan alkalmas. 

Ha ennél ,könnyedebb" szövegszerkesztőre vágynánk, ak- 
kor jó választás lehet az AbiWord is. Az , öreg motorosok" 
biztosan jól ismerik, hiszen fejlesztése hosszú ideje folya- 
matos, és több változatot is megért, valamint számos felü- 
leten érhető el (például Windowson, Linuxon, BSD-n, 
BEOS-on stb.). 

Rendkívül barátságos és kulturált program, azonnal belopta 
magát a szívembe, amint legalább 10 percet dolgoztam vele. 
Mindössze egyetlen gondom akadt, hogy a magyar nyelv- 
vel nincsen kibékülve. Ugyanis nagy meglepetésemre nem 
hajlandó kezelni a hosszú ékezetes magyar betűket. Arra 
pedig még nem sikerült ráakadnom, milyen beállítást hasz- 
nál, és hol tartja, amennyiben meglelném tehetnék valamit 
a dolog érdekében. Ennek hiányában sajnos komolyabb 
munkára még nem alkalmas, apróbb feladatokra viszont 
tökéletes, mondhatnám kihagyhatatlan jószág. 


Az iroda más területei 

Egy irodában azonban nemcsak szövegszerkesztésre és táb- 
lázatok kezelésére lehet szükségünk. Több olyan apró fel- 
adat is adódik, amelyhez szintén programháttér szükséges. 
Nos, az UHU e feladatok jelentős részében tud segíteni. 

A szótárhasználat bevett gyakorlat az irodai munkában. 
Szerencsére erre is gondoltak a fejlesztők, és az UHU-ba 
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bevették a hazai fejlesztésű [dictionary programot. Ehhez 
egyébként az UHU-Linux második lemezén találhatunk 
nyelvi bővítményeket, így a program közel húsz nyelven 
tud oda-vissza fordítani. lermészetesen nem teljes szöve- 
gek fordításáról van szó, hanem kizárólag szótárról, annak 
viszont kiváló. 

Sebessége egészen emberi, tehát egy kicsit sem lassú. Bárki 
könnyedén elsajátíthatja a kezelését, tehát az sem ördön- 
gösség. Többször használtam már munkáim során, és ki- 
jelenthető, hogy a szókincse is megfelelő a napi használat- 
hoz. Igaz, hogy mindössze az angol és a német nyelvek 
esetében próbálhattam ki, mivel a többi nyelv előfordulása 
elég csekély. 

A másik nagy sikernek örvendő (és egy irodában szinte 
nélkülözhetetlen) eszköz a Komplex CD-jogtár. 

A KJK-Kerszöv jóvoltából az UHU-Linux tulajdonosai térí- 
tésmentesen, és szabadon használhatják a programot. Maga 
az alkalmazás meglepően gyors, főleg, ha azt is tekintetbe 
vesszük, hogy (a törvénykönyvek méretéből kiindulva) 
nem kis adatbázist kell kezelnie. Ennek ellenére akárhány- 
szor használtam, szinte mindig megtaláltam benne, amit 
kerestem, és nem is sokat kellett várnom a keresés eredmé- 
nyére. Igazán remek kis program, amely szintén megállja 
a helyét a napi használatban. 

Kiskereskedelmi felhasználáshoz a LafiSoft számlázó és rak- 
tárkezelő programja lehet még érdekes számunkra. Ez is 
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magyar fejlesztésű, és hatóságok által elfogadott számlázó 
program. Az UHU-Linuxban lévő változat száz bizonylatig 
vagy hárommillió forint forgalomig szabad felhasználású. 
Több szempontból igyekeztem megvizsgálni milyen is ez az 
alkalmazás. lettem mindezt azért, mert a számlázó kényes 
pontja egy irodai rendszernek vagy vállalkozásnak. Nos, 
erre szintén ráillik a fenti megállapítás: kellemes sebességű 
és nem terheli meg a rendszert. Gyorsan , kipörgettem" 

a számlálóját, tehát nekiálltam elkészíteni a száz számlát. 
Egyetlen egyszer sem tapasztaltam fennakadást a program 
használata során. Mindvégig pontosan olyan módon, és azt 
tette, amit kértem tőle. Ez elvárható egy ilyen feladatkörű 
programtól, de mint tudjuk, ez nem mindig valósul meg. 

A DITP-s alkalmazásokból eddig igen nagy hiány volt 
Linuxon. Apróbb kezdeményezések történtek a helyzet or- 
voslására, azonban ez nem jelenti azt, hogy sikerült is meg- 
oldani a feladatot. Ilyen körülmények között, és ebben a ka- 
tegóriában indult, és győzött a Scribus. Az első olyan DIP-s 
alkalmazás Linuxra, amely képes lehet betölteni ezt az űrt, 
és a helyzet az, hogy ettől már tényleg nem sok választja el. 
Rendkívül ügyes program, amit semmi sem bizonyít job- 
ban, minthogy képes voltam létrehozni egy címlapot úgy, 
hogy életemben először ülök kiadványszerkesztő előtt. 

A program részletesebb ismertetésébe ehelyütt nem fognék 
bele, mivel a Linuxvilág januári száma több oldalon keresz- 
tül foglalkozott a Scribus képességeivel és szolgáltatásaival. 
A program egyik érdekessége (ami a kiadványszerkesztők 
között biztosan egyedülálló), hogy nyílt forrású. Első talál- 
kozásom alkalmával forráskódból kellett fordítanom. A mű- 
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velet a már megszokott módon és teljesen zökkenőmente- 
sen zajlott. Mindössze az idővel nem voltam kibékülve, 
amíg lefordult, mert ez bizony fél órába is beletelt, de cse- 
rébe egy remek programot kaptam ezért a küzdelmes fél 
óráért. Mindenki figyelmébe tudom ajánlani, mert páratlan 
élmény saját kiadványt készíteni, még akkor is, ha csak 

a saját szórakoztatásunkra tesszük. 


Ami kihagyhatatlan 
Az elkészült dokumentumokat ki is kell tudnunk nyomtatni. 
Az UHU-Linux nyomtató-kezelése igen barátságos, tehát va- 
lószínűleg ez nem jelent majd gondot. Mindenképpen java- 
solt az UHU vezérlőpult használata, amelyben a nyomtatók 
részben könnyedén állíthatjuk be a nyomtatóinkat. 
Lehetőségünk nyílik, hogy kiválasszuk milyen kapura is 
csatlakozzon a nyomtató, megadhatjuk a típusát és a gyár- 
tót is. Sőt a nyomtató protokollt is, tehát azt a programból 
megvalósított csatolófelületet, amely az adott gyártó által 
készített nyomtatónál a feladat végrehajtásáért felel. Érde- 
mes egyébként ez ügyben hallgatnunk a rendszerre, igen 
ritkán ad meg hibás értéket (Nekem még sosem tett ilyet). 
Ha azonban úgy gondoljuk, hogy finomabb beállításokat is 
szeretnénk, akkor jó választás lehet a KDE vezérlőpult is. Itt 
, finomhangolni" tudjuk az UHU vezérlőpultban már beállí- 
tott nyomtatót. Érdemes a sorrendet úgy megtartani, hogy 
először az UHU-ra bízzuk a feladatot, és csak azután kez- 
dünk kézzel hangolni a KDE-ben. Így nem hibázhatunk. 
lipp: a KDE vezérlőpultja képes megkeresni a hálózati 
nyomtatót, tehát elég csupán a tartományt megadni neki 
(IP-tartományt) és máris szétnéz a hálózaton, van-e ott 
a tartományon belül nyomtató. Kényelmes módja ez a beál- 
lításoknak, hiszen nem szükséges mindent fejből tudnunk. 
A nyomtatási művelet igazán gyerekjáték az UHU-val: szé- 
pen nyomtat, remek minőségben és általában gond nélkül. 
A sikeres (vagy annak hitt) beállítások után azonban min- 
denképpen csináljunk próbaoldalt is, illetve ha a vezérlő- 
pult megkérdezi, hogy akarunk-e ilyesmit, akarjunk. 
Ugyanis ez a legbiztosabb módja, hogy meggyőződjünk ar- 
ról, hogy valóban sikerült beállítani, jól jelenik-e meg min- 
den, és rendben zajlott-e a folyamat. 
Én egyszer sem találkoztam olyannal, hogy , elmásztak" 
volna a karakterek, rosszak lennének a színek vagy nem 
megfelelőek a betűtípusok. 
Sajnálatos módon ismét csak dióhéjban sikerült átvennünk 
az UHU-Linux irodai csomagját, hiszen olyan sok kisebb- 
nagyobb alkalmazás található benne, hogy terjedelmi okok- 
ból képtelenség mindre kitérni. Mindössze csak felületes 
képet nyújthattunk ismét, kényszerűen kihagyva olyan 
fontos kérdéseket, mint például a faxoláshoz használt eFax 
vagy Kfax ismertetése. Azonban egy dologról ismét meg- 
győződhettünk, az UHU ezúttal is újabb oldalát mutatta 
meg, mindezt úgy, hogy a programok olyan tárházát vonul- 
tatta fel, amely megvilágította, a bőség zavarával küzdünk. 
A következő hónapban kissé visszalépünk az időben, és új- 
ból a multimédia lesz terítéken. Ezúttal azonban másként, 
szigorúan zenéről lesz szó, a lejátszásáról, feldolgozásáról, 
és olyan programokról vagy megoldásokról, amelyek min- 
den felhasználó számára elősegítik kedvenceinek mentését 
tárolását és tömörítését. 

Dancsok Zoltán 
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Debian Otthonra - Szóvegfájlok vagy debconf? 47. rész) 


Avagy a kényelmes rendszergazda esete a frissítésekkel... 


gy röpke kitérőt szeretnék tenni, kedves rendszerépítő 
társaim! Eddigi cikkeimből bizonyára kitűnt, hogy 

a Debian alatt rendkívül gyorsan jönnek ki az újabb és 
újabb csomagok, ezek frissítése közben a rendszer gyakran 
megkérdezi tőlünk, hogy az új beállításfájlt felülírja-e, vagy 
pedig hagyja a rendszeren az általunk már preparált pél- 
dányt. A legtöbb esetben ilyenkor megnézzük a két beállítás- 
fájl közötti különbséget, majd tudomásul vesszük, hogy leg- 
többször nincsenek nagy különbségek. Többnyire új meg- 
jegyzések kerültek a fájlba, de mivel saját beállításaink is ben- 
ne vannak, ezért két lehetőség közül kell választanunk: vagy 
nem törődünk az új beállításfájllal és ezzel értékes adatokat 
(vagy új lehetőségeket) veszíthetünk el, vagy magunknak kell 
átírogatnunk a beállításokat a régi fájlból (ehhez egyrészt meg 
kell jegyezni a telepítés közben e fájlok nevét, másrészt a fÍris- 
sítés után gyakorolni kell kedvenc szerkesztőprogramunk 
kivágás-másolás szolgáltatásait). Szerencsére a telepítő a régi 
beállításfájlt is arendszeren hagyja, egy . dokg-old kiterjesz- 
téssel. De nincs erre egyszerűbb megoldás? 

A rendszereken általában háromféle megközelítéssel találko- 
zunk. Az egyik, hogy a felhasználónak nem adunk lehetősé- 
get közvetlenül a szöveges beállításfájl kezelésére, ekkor bár- 
milyen beállítást a rendszerhez készített karbantartó progra- 
mon keresztül kell végezzünk. Másik lehetőség, hogy a beál- 
lításfájlokkal egyszerre dolgozik a karbantartó rendszer és 
mi is. Komoly kihívás, honnan állapíthatja meg a rendszer, 
mit írhat felül és mit nem, hogy egy adott részt mi töröl- 
tünk, vagy még nem szerepel stb. Ennél a változatnál fordul 
elő gyakran az ,ezt meg ki a csuda állította át megint" típu- 
sú életérzés. Végül pedig a harmadik hozzáállás a leg- 
könnyebb és legelegánsabb úton közelíti meg a kérdést: ha 
a csomagot karbantartani szükséges, akkor a csomag készí- 
tője majd megírja hozzá a megfelelő programokat. 
lermészetesen mindegyiknek van előnye és hátránya is. 

A fejlesztők célul tűzték ki, hogy Debian alatt egy olyan 
rendszert hozzanak létre, amelyik igyekszik mindhárom 
megközelítés lehetőségét felkínálni, mégis egységes és kezel- 
hető. Legyen egy központi adatbázis is, amiben a beállításo- 
kat tárolja a rendszer, valamint a szövegfájlokban is tudjunk 
dolgozni. A rendszer magától frissítse a beállításokat, de a sa- 
ját beállításainkat se is törölje. Legyen lehetősége a csomag 
írójának saját karbantartót készíteni, mégis legyen egységes. 
Ehh, elvégre miért élünk, ha nincsenek céljaink, nem igaz? 
Eme nemes célok érdekében jött létre a debconf. Lényegé- 
ben amellett, hogy egy szabványos felületet ad a csomagké- 
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szítőknek, ezzel a karbantartó program megírásának gond- 
ját is levéve a vállukról, továbbra sem kötelező, hogy mind- 
egyik programot ezen keresztül állítsunk be. A debconf tit- 
ka, hogy saját adatbázisában is tárol minden beállítást (leg- 
alábbis azokat, amelyeket megért), valamint kipreparált be- 
állításfájlokkal dolgozhatunk. Például, ha belenézünk egy, 

a debconf által karbantartott /etc/X11/XF8oConfig-4 fájlba, 

a legelején találunk egy hosszú megjegyzésrészt, mely a kö- 

vetkezőket írja le: 

a) ez egy debconf-adatokkal dolgozó fájl, 

b) a fájl csak akkor frissül a hozzá tartozó csomag frissíté- 
sekor, ha megegyezik a debconf adatbázisában lévő 
fájllal, valamint 

c) ha a fájl más úton változott, akkor az ott feltüntetett 
parancsokkal , fogadtathatjuk el" a rendszerrel. 


A rendszer tehát tárolja a beállítási adatokat is, valamint 
egy MD5 ellenőrző kódot, ennek alapján dönti el, hogy az 
adott beállításfájl valóban megegyezik-e azzal a fájllal, amit 
ő maga hozott létre. Frissítéskor így nincs más dolga, mint 
az MD5-kódot ellenőrzi, és ha az megegyezik, nagy lelki 
nyugalommal kidobja a régi beállításfájlt, majd helyette újat 
hoz létre az általa tárolt adatok alapján. lehát, ha például az 
X11 angol billentyűzettel jelentkezik be, de már bosszant, 
hogy mindig ki kell adni a setxkbmap hu parancsot, a fent 
említett xr86config-4 fájlban megkereshetjük az alábbi 
részt, és kézzel átírhatjuk az értéket hu-ra. 


Section "InputDevice" 


Option "hu" 


EndSection 


"xkbLayout" 


Ezek után viszont bajban leszünk, hiszen a rendszer a to- 
vábbiakban nem kezeli ezt a fájlt. Ha elhitetjük a rendszer- 
rel, hogy ez az ő beállításfájlja (kiadjuk a fájl elején lévő 
md5sum parancsot, akkor viszont a következő frissítéskor (il- 
letve a dokg-reconfigure következő futásakor)) a rendszer 
úgy csapja nyakon a beállításunkat, hogy még csak nem is 
szól. De akkor mit tegyünk? A legjobb, ha megbarátkozunk 
a karbantartó felülettel, amit az előbb említett dpokg- 
reconfigre ad, s beállításainkat ezen keresztül hozzuk lét- 
re. Akkor most feleslegesen futottunk egy kört a kertben? 
Korántsem, hiszen egyrészt a szöveges beállításfájlok to- 
vábbra is megtalálhatók a rendszeren (legalább tudjuk, 


hogy hol, mit kell keresnünk), másrészt, ha valamit nagyon 
elkontárkodunk, a rendszer további eszközöket kínál 

a rendrakáshoz. Például, ha a már említett XF86Config-4 
fájlt sikerült használhatatlanná tennünk, majd az élet igaz- 
ságtalanságai fölött érzett kétségbeesett dühünk kifejezése- 
ként töröltük, a dexconf (a parancs nevében lévő x utal 

a grafikus felületre) kiolvassa az adatokat a rendszer adat- 
bázisából, majd létrehoz egy új XF86Config-4 fájlt. 

Arra is lehetőség nyílik, hogy a beállításfájl csak egy adott 
részét kezelje a debconf rendszer, sőt hivatalosan csupán 
az alábbi két sor közötti részt kezeli: 


fát BEGIN DEBCONF SECTION 
fát END DEBCONF SECTION 


Mindegyik csomag egyedi, más-más múlt áll mögötte, sőt 
nagyon sok nem is Debian alatt készül, így lassú folyamat, 
hogy a csomagok mindegyike teljes mértékben megfeleljen 
a debconf igényeinek. A rendszergazdák életét viszont 
rendkívül megkönnyíti, feltéve, hogy az ember veszi a fá- 
radtságot és végigjátssza az összes párbeszédablakot. Sze- 
rencsére a kezelőfelületet mi magunk választhatjuk meg. 
Ezekből a felületekből egyre többet találunk. És hogy a hó- 
hért is akasszuk, a dokg-reconfigure debconf paranccsal 
beállíthatjuk az alapértelmezettként használni kívánt beállí- 
tási környezetet. 

Így könnyedén beállíthatjuk, például a különböző kódla- 
pok támogatását (dpkg-reconfigure locales), vagy a ka- 
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rakteres terminálokon használt billentyűzetkiosztást (dpkg- 
reconfigure console-common), még egy érdekes felhaszná- 
lási területet emelek ki, ez pedig a /etc/alternatives könyvtár. 
Debian alatt sokszor találkozunk a bőség zavarával: előfor- 
dulhat, hogy öt-hat terminálprogram is csücsül a gépen 
(xterm, rxvt, konsole, mI term stb.), a felhasználó viszont 
csak ,egy terminálprogramot" szeretne indítani. Ekkor jön 
a képbe, hogy jó volna beállítani alapértelmezett programo- 
kat ilyen-olyan feladatra. Régen ezt egy-egy környezeti 
változóval oldották meg, ennek az a hátulütője, hogy nem 
rendszerszintű, valamint minden egyes felhasználónak 
meg kell találnia (például) a .bashrc fájlt. A Debianban, ha 
egy program ,egy szerkesztőt" akar indítani, akkor a /etc/ 
alternatives/editor-t indítja, ezzel leegyszerűsíti az életet. 
Ha például be akarod állítani, hogy melyik grafikus be- 
jelentkezéskezelő induljon a gépen, akkor az itt lévő 
x-sessi0on-manager hivatkozást kell a megfelelő értékre ál- 
lítani. De lehetőleg ne kézzel állítsd át, hanem az update- 
alternatives --config x-session-manager paranccsal. 
Na igen, a rendszergazdáknak előbb-utóbb jól jön, ha 
gyorsan tudnak gépelni. (Gondolom, nem meglepő, hogy 
hasonló eredményt érünk el azzal is, ha például a dpkg- 
reconfigure xdm parancsot adjuk ki). 

Előre tehát az egységes és használható beállításfájlok útján! 
Bár a Debian által választott út néha valóban nehezebb, 
mint egyszerűen beleírni egy szövegfájlba, de hosszú távon 
mindenképp megéri a fáradalmakat. 


Szy György 
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Hogyan térjunk át Linuxra lépésről lépésre (8. rész) 


Mozgóképek lejátszása Linux alatt. 


efejező részéhez érkezett az áttérésről szóló kezdő 
felhasználóinknak szánt sorozatunk. Mivel az előző 
részében megismerkedhettünk rendszerünk képke- 
zelő megoldásaival, innen valóban csak egyetlen lépés 

a mozgóképek világa, így végezetül elérkezettnek láttam, 
hogy megnézzük mire képes a Linux a digitálisan tárolt 
képanyagok megjelenítése terén. Írásaimban megszokhat- 
ták tőlem, hogy ilyenkor az elején mindig fényezem egy ki- 
csit a Linuxot, s megpróbálom elmagyarázni, hogy mennyi- 
vel jobb, mint bármi más. Ezzel természetesen soha nem az 
a célom, hogy elfogultsággal szóljak, és megpróbáljam , ráe- 
rőszakolni" az emberekre a linuxos megoldásokat - a Linux- 
nak, úgy érzem, nincs is erre szüksége. Arra viszont igenis 
szüksége van, hogy a figyelmet az egyébként könnyedén 
elérhető megoldások felé irányítsuk, s egyben feloldjuk 
azokat a feszültségeket, amelyek az egyes felhasználókban 
egy-egy kudarcélmény után kialakulhattak. E régi szoká- 
somhoz most is hű maradok, és gyorsan vázolom is, milyen 
jó kis eszközök közül válogathatunk a linuxos videóleját- 
szás területén. Bár a válogatás szó jelen esetben kicsit túl- 
zás, ugyanis egyetlen olyan, SuSE alatt is könnyedén elér- 
hető lejátszó létezik, amely teljes értékű, de a mindennapok 
során a többivel is elboldogulunk. A hatékony és igazán jól 
használható linuxos mozgóképkezelés mindössze egy-két 
évre nyúlik vissza, ugyanis akkor készültek el az első ver- 
senyképes lejátszók. Azóta három fő vonal alakult ki (ezek 
azért egy irányba haladnak), s létezik a mai napig is. Az 
egyik a Xine lejátszó által nyújtott megoldás, a másik az 
MPlayer vonal, a harmadik pedig a nem is oly régi, ám an- 
nál tetszetősebb VLC, amely a VideoLAN műsorszóró pro- 
jekt ügyfélprogramjának indult, de mellékesen egy igen jól 
használható médialejátszó kerekedett belőle. Jelenleg az 
MPlayer javára látszik eldőlni a verseny, de személyes ta- 
pasztalatom, hogy a kezdők számára a VLC kínálja a vá- 
lasztható megoldást. Ugyan gyengébbek a képességei, de 
nincs fordítás, semmi fejlesztőicsomag-telepítés, csak meg 
kell etetni a rendszer csomagkezelőjével és máris használ- 
ható. Ez így szépen és jól is hangzik, ám a telepítés során 
SuSE 9.0-s alatt rettenetesen meggyűlt vele a bajom (más 
terjesztések alatt a telepítés gyerekjátéknak bizonyult). 

Ha ügyesek vagyunk, akkor itt is be tudunk húzni a na- 
gyoknak a rendkívül hatékony MPLayerrel, de talán még- 
sem olyan egyszerű és teljes a kép, mint a mindennapi fel- 
használás többi területén. Léteznek alapértelmezetten tele- 
pített vagy könnyen telepíthető lejátszók, ezekkel ugyan 
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m xina video output 3 eszet se 


This version of xine may lack certain features because 
of legal regvirements (potential patent violations), 
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A Xine — indítás után 


semmi dolgunk nem akad, de a tudásuk rendszerint erő- 
sen elmarad akár a Windows Media Player nyújtotta szol- 
gáltatásokhoz képest is. (Ennek fő oka egyébként a fizetős 
szabványokban és a különböző jogi fenyegetésekben 
keresendő.) A kínálat másik felén találhatók a fordítandó 
vagy SuSE alatt nehezen telepíthető lejátszók, ezek már 
mindent tudnak, de meg kell értük szenvedni - ezt sokan 
nem szeretik. Vigasztalásul elmondom, hogy ez csak a SuSE 
esetében van így, ugyanis más terjesztések (Red Hat, vagy 
Debian) alatt egyszerűen elfelejthetjük akár a teljes értékű 
Xine-t vagy a VLC-t, s a nehézség át is van hidalva. Meg- 
jegyzendő, hogy a SuSE is tartalmaz egy Xine-t, azonban 
ez csökkentett képességű, például nem lehet vele DVD-t 
lejátszani — bizonyos szerzői jogi és szabványügyi gondok 
miatt. 

Bár az eddig bemutatott terjesztésnek ez a terület az egyet- 
len komoly gyenge pontja, azért nem kell megijednünk, 
azonnal megtanuljuk, hogyan is kell videókat lejátszani, 
könnyen és gyorsan. 


Elméleti alapok 

Hely hiányában természetesen nem kezdhetek bele a digi- 
tálisan tárolt videók teljes elméletének ismertetésébe, de 
szeretném összefoglalni nagyon röviden az alapvető dolgo- 
kat, amelyeket mindenkinek célszerű ismernie. 

A digitális videók közös tulajdonsága a hatalmas méret. 
Nem csoda ez, hiszen másodpercenként 25-30 nagyfelbon- 
tású képet kell tárolnunk. Ez hagyományos formában kivi- 





A Xine (forrás: 8 http://xine.sf.net) 


telezhetetlen, ezért az ilyen módon tárolt képanyagot bo- 
nyolult eljárásokkal tömörítik, a képek egyes elemeit pedig 
egyenesen veszni hagyják. A cél az, hogy az átalakítás után 
élvezhető minőségű, ugyanakkor kevés tárhelyet igénylő, s 
viszonylag kis számítási kapacitás igénybevételével lejátsz- 
ható adatfolyamot kapjunk. Ezt többnyire úgy érik el, hogy 
a mozgóképek egyik fontos tulajdonságát aknázzák ki, ne- 
vezetesen az egymást követő képkockák csak kis mértékben 
különböznek egymástól. Így egy jelenet elején tárolnak egy 
képet, s a továbbiakban már csak az szerepel, hogy a követ- 
kező képkockák a megelőző képkockáktól miben térnek el. 
Ez egészen addig megy, amíg a különbség leírása kevesebb 
helyet igényel, mint egy új, úgynevezett kulcsképkocka be- 
szúrása. Ezek a bizonyos kulcsképkockák olyan, az adott 
jelenetre jellemző képek, amelyek valóban tárolva vannak, 
és a későbbiekben ezekhez viszonyítva írják le az őt követő 
képkockák különbözőségét. Ezeket a számításokat, és ma- 
gát a tömörítést kódolóprogramok végzik. Hasonlóan a le- 
játszás során a tömörítés fordítottját is ilyen eljárások vég- 
zik, amelyeket dekódolóprogramoknak nevezünk. A kettőt 
általában össze szokták vonni, így kapják meg az adott for- 
mátumra jellemző kodeket (kóder — dekóder). A legtöbb le- 
játszó ezeket a kodekeket (és egyéb eljárásokat) hívja segít- 
ségül, és velük végezteti a mozgóképtartalom visszafejtését, 
s ezek után adja át a képanyagot a rendszernek (általában 
X-felület), hogy jelenítse meg. A lejátszó tehát , csak" a fájlok, 
médium kezeléséért, az adatok kinyeréséért, a kép-hang 
összehangolásáért és a vezérlésért felelős. Mindez természe- 
tesen iszonyatos feladat. Ennyit dióhéjban, most pedig néz- 
zük a rendelkezésünkre álló eszközöket. 


Mindenekelőtt a nagy öreg: a Xine 

Ez a legelső ,komoly" linuxos lejátszóprogram, melynek 

a kezdetekben számtalan hibája mellett az is akadályozta 
az elterjedését, hogy rendkívül nehéz volt működésre bírni. 
Szerencsére ez az állapot hamar változott, s a későbbi ki- 
adások már egészen egyszerűen telepíthetők voltak. Mára 
ezen a téren vezeti a mezőnyt, vagyis ez a legegyszerűbben 
használatba vehető lejátszó az összes közül. Ezen túlmenő- 
en alapértelmezetten rendelkezik grafikus felülettel, ennek 
következtében a kezelése is gyerekjáték: semmivel sem ne- 
hezebb, mint bármely operációs rendszer valamelyik mé- 
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Dobbantó 


dialejátszójának használata. A könnyed kezelésért azonban 
fizetni kell: a Xine mind tudásban, mind a grafikus felület 
sebességében alulmarad a versenytársakhoz képest. Néz- 
zük meg, hogyan telepíthető, s eközben ismerkedjünk meg 
a lejátszó képességeivel is. 

Ami a telepítést illeti, sok dolgunk nincs, ugyanis a Xine jó 
néhány változat óta része a SuSE-terjesztéseknek, nekünk 
csak annyi a dolgunk, hogy a YaSI csomagkezelő moduljá- 
val megkeressünk a xine-ui nevű csomagot, majd hozzá- 
adjuk rendszerünkhöz. A program a xine parancs kiadásá- 
val indul. Ekkor egy tetszetős logó után egy ablakot ka- 
punk, melyben a rendszer rögtön kiírja, hogy a lejátszó 
csak korlátozott képességekkel bír bizonyos jogviták elkerü- 
lése érdekében. Ennek egyik részén egyszerűen segíthe- 
tünk, ugyanis könnyedén hozzáadhatjuk a Windows alatt 
használatos kodekeket. A másik tiltott szolgáltatáson — ne- 
vezetesen, hogy nem játszhatunk le DVD-t — azonban már 
csak úgy segíthetünk, hogy kézzel telepítjük a Xine honlap- 
járól (2 http:/xinehg.de/) letöltött változatot. Mi kezdetnek 
maradjunk csak az alapértelmezetten elérhető változatnál. 
A program vezérlőfelületét úgy hozhatjuk elő, hogy jobb 
gombbal kattintva a megjelenő gyorsmenüből kiválasztjuk 
a GUI menüpontot. Ha ezt megtettük, máris láthatjuk mire 
képes a lejátszó: megnyithatjuk a lemezen tárolt videókat, 
VCD-t vagy SVCD-t játszhatunk le, ha DVB (Digital Video 
Broadcasting) kártyánk is van, akkor digitális tévéadást néz- 
hetünk, s elvileg DVD-t ugyancsak lejátszhatunk, de mint 
már említettem, a jogviták elkerülése végett ezt a lehetősé- 
get kivették a SuSE-terjesztésben lévő lejátszóból. Ha már 

a csonkított képességeknél tartunk: az alapfelállás szerint 

a lemezen tárolt videóinkkal, amennyiben nem MPEG for- 
mátumúak, igencsak meggyűlhet a bajunk, ugyanis a Xine 
e változata mindezt nem kezeli. Ennek az az oka, hogy nem 
rendelkezik a videók kicsomagolásához szükséges 
kodekekkel. Ne keseredjünk el, inkább lássuk a megoldást! 
Az interneten kering egy Linux alatt használható, DLL-eket 
tartalmazó kodekcsomag. Nekünk csupán ezt kell letölteni, 
s a benne lévő állományokat kicsomagolni a /usr/lib/win32 
könyvtárba. Ha ez megvolna, indítsuk újra a lejátszót. Most 
már mindenféle DivX-es vagy más formátumú filmet megte- 
kinthetünk a lejátszó segítségével, ugyanis a Xine felismeri 
az ebben a könyvtárban elhelyezett, eme különleges kode- 
keket, s ha szükség van rájuk, alkalmazza is őket. Ilyen ko- 
dekcsomag, amit egyébként win32 csomagnak is neveznek, 
a 2 http:/www.mplayerhg.hurreleases/codecs/ tölthető le. 

A használhatóságot tekintve a program a mindennapi élet- 
ben tökéletesen megállja a helyét: szinte mindent lejátszik, 
amit odaadunk neki, sőt menet közben több hangsáv és fel- 
irat közül tudunk választani, képet menthetünk a filmből, 
testreszabhatjuk a beállításokat, s mindezt grafikus felüle- 
ten keresztül tehetjük meg. Ezenkívül a Xine parancssorból 
is nagyszerűen használható, a fortélyok elsajátításához 

a Xine kézikönyv tanulmányozását javaslom, ezt a man xine 
parancs kiadásával nézhetjük meg parancssorból. 


Egy Xine előlap: Kaffeine 
Ez a KDE munkakörnyezethez tartozó médialejátszó való- 
jában nem más, mint egy Xine előlap (frontend). Ez azt je- 


lenti, hogy az előttünk lévő felület nem , igazi" programot 
takar, hanem minden kiadott utasításkor a Xine-t hívja se- 
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gítségül a háttérben, s az ő képességeit kihasználva jeleníti 
meg a videót. Miért jó ez nekünk? Igazából az lehetett a cél, 
hogy a KDE grafikus munkakörnyezetet többnek lássuk, 
mint ami valójában. lovábbá egyéb haszna is akad a dolog- 
nak, míg a Xine mutatós, cifra felülete nehézkesen lassú, 
addig a Kaffieine igen fürgén mozog, a KDE fájlpaneljét 
használva pedig sokkal egyszerűbben nyithatunk meg állo- 
mányokat. Képességeit tekintve pontosan ugyanazt tudja, 
mint a Xine, sőt a beállítópanelje a Xine hasonló feladatú 
ablakának tökéletes mása, azaz mindent testre tudunk szab- 
ni a segítségével. Ezen felül a program a szokásos területi 
beállítások használatával magyarul beszél, tehát mindenki 
könnyebben igazodhat el rajta. Ez a lejátszó SuSE 9-es alatt 
alapértelmezetten része a rendszerünknek, így a telepítésé- 
vel nem is kell bajlódnunk. Sajnos a program a korlátait is 
megőrizte, tehát DVD-t továbbra sem tudunk lejátszani, s 

a változatos formátumú videofájllal is csak akkor boldogu- 
lunk, ha telepítjük a win32 kodekeket. 


VLC — a rendszeridegen 

A VLC-t azért illettem e jelzővel, mert SuSE alá telepíteni 
nem is olyan egyszerű feladat. Ennek az oka, hogy a 9.0-s 
változathoz nem létezik hivatalos csomag, így aki bajlódni 
akar vele, annak a Red Hathez kiadott változatot kell meg- 
próbálnia működésre bírnia, ami már csak azért sem egy- 
szerű, mert körülbelül 18 csomagból áll, s ezek mindenféle 
rendszercsomagokat igényelnek. Mivel a telepítési útmuta- 
tó meghaladja e cikk méretét, ezért ez esetben kihagyom, 
viszont néhány szót mégis ejtenék róla, mivel más terjeszté- 
sek alatt egyszerűen hozzáadható a rendszerhez, s mind- 
emellett rendkívül kedvező tulajdonságokkal bír. Személyes 
véleményem szerint messze jobb, mint a Xine, arról már 
nem is beszélve, hogy egy teljes műsorszóró megoldást le- 
het ráépíteni. (Linuxvilág 39. szám ,Műsorszórás a helyi há- 
lózaton"; 40. szám , Műsorszórás: nem csak helyi hálóza- 
ton"). Maga a program eredetileg e műsorszóró megoldás 
ügyfélprogramjaként lépett a fejlődés útjára, de mellékesen 
remek médialejátszó lett belőle, hiszen helyi környezetben 
is pontosan ugyanazt kell tudnia a képek megjelenítéséhez. 
A program rendelkezik grafikus felülettel, de erre is igaz, 
hogy parancssorból is kényelmesen vezérelhető. Ezzel 

a programmal számos fájlformátum megtekinthető, ugyan- 
is alapértelmezetten tartalmazza a híres, nyílt forrású 
libavcodec nevű kodekcsaládot, amellyel MPEG2 adatfo- 
lyamtól kezdve az XVID AVI fájlokig bármit lejátszhatunk, 
méghozzá nem is akármilyen hatékonysággal. A DVD ko- 
rongok lejátszása is gyerekjáték, ugyanis a lemez behelye- 
zése után a Fájl menü Megnyitás panelének kiválasztása 
után akár a DVD-n található menü igénybevételével is 
használhatjuk a korongot, sőt mi több, az általam kipróbált 
lemeznél hibátlanul működött. (lIermészetesen a menüt 
mellőzhetjük is, így kihagyhatjuk az unalmas reklámokat, 
illetve a jogi figyelmeztetéseket.) 

Felületét tekintve leginkább a Windows alatt elérhető 

Xing MPEG-lejátszóra hasonlít, egész kényelmesen hasz- 
nálható, s figyelemreméltó az is, hogy szinte mindent be- 
állíthatunk a grafikus felületről is. A program egyébként 

a legtöbb operációs rendszerhez rendelkezésre áll, bát- 

ran javaslom mindenkinek, hogy alkalmazza más felü- 
leten (platform) is. 
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Fájl Lejátszás Nézet Beállítások könyvjelzők Segítség 


Xine hiba; ismeretlen hiba 





A Kaffeine médialejátszó 


Büszkeségünk: az MPlayer 

Immáron több éve ül trónján a magyar fejlesztésű médiale- 
játszó, az MPlayer. Igazi erejét az adja, hogy szinte az 
összes létező fájltormátummal megbirkózik. Ezenkívül 

a kezdetek óta rengeteget egyszerűsödött a telepítése, szol- 
gáltatásai a csillagos égig érnek, bármit megoldhatunk vele, 
s mindezt profi módon. Régebbi SuSE-terjesztésekben volt 
előre fordított MPlayer, ám nem megfelelően működött. 
lalán ezért is hagyták ki a 9-es változatból. Egyéb gondot 
jelenthetett az is, hogy ez a lejátszóprogram nem igazán 
terjed előre fordított formájában, ezt bizony fordítani kell. 
Szerencsénkre a kezdetben sokat szidott bonyolult fordítási, 
telepítési folyamat mára jelentősen leegyszerűsödött, oly- 
annyira, hogy mi, kezdő linuxos mazsolák első fordítási 
gyakorlat gyanánt most meg is próbálkozunk vele. Célom 
egy olyan telepítési útmutató leírása, amit pontosan követ- 
ve bárki akadálytalanul hozzájuthat a világ jelenleg legnép- 
szerűbb linuxos médialejátszójához. Kezdjük is el mindjárt! 
Mint tudjuk, a linuxosok életében elég gyakori a mumus- 
ként emlegetett , fordítás", amely nem takar mást, mint 
egy alkalmazás programnyelvről binárissá történő átalakí- 
tását. Hacsak nem vagyunk fejlesztők, Windows alatt 
ilyesmivel nem találkozhattunk, ugyanis a kereskedelmi 
programok kódja szigorúan őrzött titok (pestiesen talán 

a disznósajt lehetne), ezért mindig a lefordított változattal 
találkozhattunk. A nyílt forrás világában azonban — mint 
a neve is mutatja — a program kódja szabadon elérhető, 
terjeszthető és változtatható stb. Ezért időnként előfordul, 
hogy az alkalmazás nem a végleges formájában kerül 
elénk, hanem azt először át kell alakítani, azaz le kell for- 
dítani a processzorunk által emészthető formára. Ez sok 
esetben azért előnyös, mert így pontosan a gépünkre il- 
leszkedő program keletkezik, éppen úgy, mintha egy öl- 
tönyt nem a boltban veszünk meg, hanem a szabó szabja 
ránk. Az MPlayerrel is ez a helyzet, s régen a gyengébb 
képességű gépek esetében bizony jelentős processzoridőt 
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A VLC DVD-lejátszás közben 
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lehetett megtakarítani, ha az előrefordított változat helyett 
mi magunk készítettünk binárist a forrásból. 

Járjunk el most is ekként, és mindenekelőtt 

a 5 http:/www.mplayerhg.hu/homepage/design6/dload.html 
címről töltsük le az MPlayer forrását, a feliratok használatá- 
hoz szükséges betűtípusokat (I508859-2 kódolással), és eset- 
legesen a tentebb már említett win32 kodekcsomagot. Ez 
utóbbit a /usr/lib/win32 könyvárba bontsuk ki alkönyvtárak 
nélkül, az MPlayer forrását pedig csomagoljuk ki egy tetsző- 
leges könyvtárba a Midnight Commander segítségével 

a Windows alatt megszokott módon, természetesen mindezt 
rendszergazdaként kell megtennünk. Ezután a YaSI csomag- 
kezelőjével telepítsük a gcc, xfree86-devel, illetve a make 
nevű csomagokat. Ha ez megvolna, indítsunk újra parancs- 
sort, s lépjünk be abba a könyvtárba, ahová az MPlayer for- 
rását kicsomagoltuk. Adjuk ki a . /configure parancsot, 
amely a környezet önműködő felismerését, s a fordításhoz 
szükséges beállításokat egyaránt elvégzi. Ha ez hiba nélkül 
lefutott (erre minden esélyünk megvan), adjuk ki a make pa- 
rancsot, amely az úgynevezett makefájlban megadott kap- 
csolók, jellemzők alapján a gcc (GNU C Compliler) segítségé- 
vel megkezdi a fordítást. Pár perc múltán végezni is szokott, 
ilyenkor némi felhasználói tájékoztatást ír ki a képernyőre, 
például hogyan telepítsük a már lefordított programot, illet- 
ve hova másoljuk a betűtípusokat. Foglalkozzunk most az 
elsővel, s adjuk ki a make instal ] parancsot, amely az előre 
megadott utasítássorozat lefuttatásával a megfelelő helyekre 
másolja a program összetevőit. Ezzel gyakorlatilag a program 
már működőképes, de mielőtt birtokba vennénk, a letöltött 
betűtípusokat csomagoljuk ki egy átmeneti könyvtárba, majd 
annak az alkönyvtárnak a tartalmát, amely a számunkra ked- 
vező méretű betűtípust tartalmazza, másoljuk a /usr/local/ 
share/mplayer/font könyvtárba. Ezennel készen is vagyunk. 
Ha most szeretnénk megnézni egy videót, adjuk ki az 
mplayer cfájl neves parancsot, s a dolog máris működik. 
A program a DVD-k lejátszását is alapértelmezetten támo- 
gatja. Ehhez nem kell más tennünk, mint a korong behelye- 
zése után kiadni az mplayer dvd: //1 parancsot. Hasonlóan 
járjunk el VCD/SVCD esetében is, de ott dvd helyett a vcd 
eszközt címezzük. 

Ezen túlmenően természetesen lehetőségünk nyílik távoli 
fájlok HTIP protokollon történő lejátszására is. Nem túl 
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Az MPlayer működés közben 


meglepő módon, ezt az milayer http://URL parancs 
kiadásával tehetjük meg. Az MPlayer igazi erőssége azon- 
ban az, hogy számtalan kapcsolójával tökéletesen beállít- 
hatjuk a lejátszási jellemzőket. Ami a felhasználói beavat- 
kozást illeti: gyakorlatilag verhetetlen. Ez egyébként lehe- 
tővé teszi számunkra, hogy a lejátszó képességeit a vég- 
telenségig kihegyezzük, de ez még nem minden. 

A program ennél sokkal-sokkal többet tud, szinte mindent, 
ami csak az eszünkbe jut. A forrás könyvtárában a DOCS/ 
Hungarian alkönyvtárban teljes körű, magyar nyelvű 
használati utasítás található. Az MPlayer részletes bemu- 
tatására hamarosan ismét sort kerítünk egy önálló cikk 
keretében. Addig is javaslom mindenkinek, hogyha ked- 
vet érez, kezdje el az ismerkedést ezzel a nagyszerű 
alkalmazással. 


Búcsúzóul 

Ezzel befejeződött a SuSE Linuxon keresztül történő bemu- 
tatkozása, ez egyúttal a cikksorozat végét is jelenti. A dolog 
természetesen nem fog elhalni, hanem áttér egy általáno- 
sabb, terjesztésfüggetlen környezetbe. Ez azt jelenti, hogy 
a továbbiakban is szeretném megtartani azt a vonalat, hogy 
egy-egy felhasználási területet kiragadva megvizsgáljuk 
milyen megoldások léteznek az adott feladatra, de mindezt 
általánosan, s nem is az áttérés, hanem a további használat 
jegyében, így keltre életre egy újabb cikksorozatot. 

Ha már így a végére értünk, szeretném megragadni az al- 
kalmat, hogy megköszönjem minden olvasónknak a soro- 
zattal kapcsolatban érkezett számtalan levelet: kérdést, vé- 
leményt, észrevételt — ezeket továbbra is várom. Örömmel 
vettem minden hozzászólást, jólesett minden dicsérő szó, 
igyekeztem válaszolni minden kérdésre, s mindent össze- 
vetve jó volt átélni, hogy mindaz, amit eddig tapasztaltam, 
s most megpróbáltam átadni, az olvasói oldalon gazdag 
táptalajra talált. Köszönöm! 


Komáromi Zoltán 
(komiokiskapu.hu) 

23 éves, a BME hallgatója, mellette 
PHP-programozóként dolgozik. 
Kedvenc területe a multimédia. 





2004. június 69 


e Tt 


0 Kiskapu Kft. Minden Jog fenntartva 











CÖ 
B 
h 
1 
CÖ 
. 
c 
ez 
DD 
4— 
0) 
Zs 
E 
DD 
"OO 
s 
2 
ád 
4— 
Ms 
-J 
(698 
40 
az 
s 
Ms 
o 


Linuxos kiszolgálót mindenkinek! (7. rész) 


A SuSE Linux mint kiszolgáló - kisvállalati és otthoni környezetben. 


tf a 


ikksorozatunk előző részeiben népszerű internetes 
C és hálózati szolgáltatások kiszolgálását tettük lehe- 

tővé rendszerünkön. Most az egyik leggyakrabban, 
bár kétség kívül nem a leglátványosabban használt szolgál- 
tatást fogjuk megismerni, nevezetesen a DNS-t, azaz a tarto- 
mánynév szolgáltatást (DNS — Domain Name Service). 


Az elméletről dióhéjban 

Mint azt bizonyára mindenki tudja, az internetre kapcsolt 
gépek mindegyike rendelkezik egy ÍP-címmel, amelyen ke- 
resztül az adott gép megszólítható bármelyik másik háló- 
zatba kapcsolt gépről. Mivel az IP-címek 32 bites számok, 
ezért e számokból akár csak a kedvenc weboldalaink címét 
megjegyezni is felér egy fél telefonkönyv megtanulásával, 
nem beszélve az egyéb felmerülő nehézségekről. 

Az előbbiekből kiindulva már a ICP/IP-hálózatok megjele- 
nésekor felmerült az igény, hogy az egyes gépeket ne csak 
IP-cím szerint, hanem egy választott név alapján is meg le- 
hessen találni. Ehhez egy olyan adatbázis szükséges, amely- 
ben név és cím párok szerepelnek. 

A Unix-rendszerekben kezdetben ez az adatbázis 

a hosts.txt állomány volt. Ebbe az állományba gyűjtötték 
a név és cím párokat, és ha egy gépre a neve alapján hi- 
vatkoztak, akkor a rendszer ebből az állományból kereste 
ki a névhez tartozó IP-címet. Ezt az adatbázist a Stanford 
Research Institute-nál (SRI) működő Network Information 
Center (, the NIC") tartotta karban. Amikor új gép je- 

lent meg a hálózatban, a választott névvel bejegyezték 

a hosts.txt állományba, majd hetente egyszer vagy két- 
szer közzétették a legújabb frissítést, hogy az új név—cím- 
párokat elérhetővé tegyék. 

Ez a rendszer tökéletesen működött néhány tucat vagy pár 
száz név tárolására, ellenben a jelenlegi címigények kielégí- 
tésére használhatatlan. 

lovábbi gondot jelentett, hogy a hosts.txt adatbázisába bár- 
ki megkötés nélkül helyezhetett el bejegyzéseket, így meg- 
volt annak a lehetősége, hogy kellő szabályozás híján egy- 
mással ütköző neveket helyezzenek el az állományban, ez- 
zel téve használhatatlanná. 

A hosts.txt utóda a mai napig megtalálható mind a Unix- és 
Linux-, mind a Windows-rendszerekben. Előbbieknél a /etc/ 
hosts állományt kell keresni, utóbbinál a JoSystemRoot9o/ 
system32/drivers/etc/hosts állományt. 

Paul Mockapetris 1983-ban megalkotta a Domain Name 
System (DNS) nevű név és cím párosítási rendszert. Az öt- 
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let egy hierarchikus rendszeren alapul, amelyben a tarto- 
mányneveket faszerkezetbe rendezetten szeretnénk tárolni. 
A faszerkezetbe rendezés több előnnyel is bír: jól átlátható 
az általa leírt szervezeti szerkezet, valamint megfelelő fa- 
szerkezet esetében a keresés nagyságrendekkel hatéko- 
nyabb, mint a hagyományos listában való keresés. 

A fa gyökere az úgynevezett fő gyökér (root). Ezt az eredeti 
DNS-rendszerben egy ponttal jelölték. A gyökér alatt talál- 
ható első szint az úgynevezett legfelső szint (top level). Ez 
alatt pedig a másodszintű tartománynevek (second level) 
találhatóak. 


A Top Level Domain 

A legfelső szintű tartománynevek (lop Level Domain, ILD) 
egyedi nevek, ezeket a nemzetközi szervezetek osztják ki, 
illetve a használatuk körét is ők határozzák meg. A legfelső 
szintű tartománynevek közé tartoznak a következő három- 
betűs nevek: com, org, net, edu, int, mil, gov. Ezek közül 

a mil és a gov különlegesek, mivel előbbit csak az Egyesült 
Államok hadserege használhatja, míg utóbbit csak az Egye- 
sült Államok kormányzati szervei. A többi legfelső szintű 
tartománynév alá gyakorlatilag szabadon lehet neveket be- 
jegyezni, legfeljebb működési, tevékenységi köri megköté- 
sek vonatkoznak rájuk. 

A legfelső szintű tartománynevek másik nagy csoportja 

a kétbetűs országkódok csoportja. Ezeket a kétbetűs kódo- 
kat az ISO (International Organization for Standardization 
- Nemzetközi Szabványosító Szervezet) osztotta ki az or- 
szágoknak. 

Az előbb említett legfelső szintű tartományneveken kívül az 
elmúlt években újabb tartományok jelentek meg a legfelső 


szinten, ilyen a .biz vagy a .info. Az összes jelenleg elérhető 

nem országokat jelölő legfelső szintű tartománynév és a ko- 
ordináló szervezeteik elérhetősége a 3 http:/wwwi.iana.org/ 
gtld/gtlid.htm címen található meg. 


Másodszintű tartományok 

A másodszintű nevek kiosztása mindig az adott legfelső 
szintű tartománynév fenntartójának a feladata, így a .hu 
alá tartozó címeket a magyarországi NIC szervezet osztja 
ki, mely a 5 http:/www.nic.hu címen érhető el. 
Amennyiben valaki a .hu tartománynév alá szeretne nevet 
bejegyeztetni, akkor ennek feltételeiről és a választható, va- 
lamint a már foglalt nevekről a 5 http://www.domain.hu 
címen tájékozódhat. 

Másodszintű tartománynevet bárki szabadon bejegyezhet, 
viszont szerencsés lenne, ha a nemrég beindult , jegyez- 
zünk be minden értelmes szót" mozgalom visszaszorulna 
kicsit, ugyanis — amellett, hogy lassan nem lehet értelmes, 
még be nem jegyzett szavakat találni — azzal, hogy lassan 
minden internetre kapcsolt gép saját másodszintű névvel 
rendelkezik, elvesznek a DNS felépítéséből származó olyan 
előnyök, mint a kiegyensúlyozott fában való keresés vagy 
a szervezeti felépítések leírása. 


A DNS működéséről 


A DNS működése egy elosztott adatbázison alapul, ez je- 
lenleg a világ legnagyobb ilyen típusú rendszere. A DNS- 
rendszer jelenleg 13 úgynevezett fő (root) kiszolgálóból és 
számtalan kisebb-nagyobb DNS-kiszolgálóból áll. A 13 fő 
DNS különleges feladatot lát el, nevezetesen az ő feladatuk, 
hogy minden egyes tartományhoz ismerjék a kiszolgálógé- 
pet vagy az oda vezető utat. 

Amikor egy felhasználó egy weboldal letöltését kezdemé- 
nyezi a böngészőjéből, a gépe megnézi a saját DNS-gyorstá- 
rát (cache), hogy az adott címhez tartozó IP megtalálható-e 
benne. Amennyiben nem találta meg az IP-t, akkor megszó- 
lítja a rendszernek megadott egyik DNS-kiszolgálót. Ez 

a DNS-kiszolgáló szintén megpróbálja a névhez tartozó cí- 
met megtalálni, ehhez átnézi a saját adatbázisát, valamint 

a saját gyorstárát. Minden DNS-kiszolgáló szintén rendel- 
kezik gyorstárral, amelybe a legutóbb használt név—cím- 
párokat raktározza el. Amennyiben a megszólított DNS-ki- 
szolgáló sem találja meg a név feloldását, akkor a hozzá 
földrajzilag legközelebb eső fő DNS-hez fordul. A tő DNS 
visszakeresi a névhez tartozó kiszolgálót és elküldi a címet 
a DNS-kiszolgálónknak, aki ezt a címet egyfelől eljuttatja 
hasznosítás céljából. Felmerülhet a kérdés, mi szükség van 
a ritkán használt címek tárolására. A válasz roppant egysze- 
rű: a ritkán használt címet sem csak egyetlen egyszer hasz- 
náljuk, hanem az adott weboldal megtekintése során is 
többször szükségünk lehet rá. 

Egy DNS-kiszolgáló több tartomány, zóna kiszolgálását 

is lehetővé teszi. Ilyenkor minden egyes zónához tarto- 

zik egy állomány, amely leírja az adott zónába tartozó 
név-cím-párokat. Ha egy gép adott zónához kéréssel for- 
dul, a kiszolgáló megkeresi a zónaállományban a kérdéses 
bejegyzést, és amennyiben eredményes volt a kérés, akkor 
visszajuttatja az őt megszólító géphez. Ezek a kérések és 
válaszok minden esetben UDP-n (User Datagramm 
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Protocol) keresztül futnak. Az UDP protokoll előnye a TICP- 
hez képest, hogy mivel nincs kapcsolatfelépítés, valamint 
nem megbízható kapcsolaton zajlik a kapcsolattartás, ezért 
a ICP-hez képest lényegesen kisebb adatfolyamot hoz lét- 
re, valamint sokkal rövidebb idő alatt megy végbe a lekér- 
dezés. lermészetesen hátrányként jelenik meg a csomag- 
vesztés, de ez nem gond, legfeljebb mind a kérést, mind 

a választ újraküldjük. 


A gyakorlat 

Jelenleg a Linux alatt a legelterjedtebb DNS-kiszolgáló 

a BIND, azaz a Berkeley Internet Name Domain, annak is 

a 8-as, illetve újabban a 9-es kiadása. SuSE alatt a YaS1-tal 
természetesen mindkét kiszolgáló telepíthető, előbbi 

a bind8, utóbbi a bind9 csomag telepítésével. Én az utóbbi 
telepítését javaslom, tekintettel arra, hogy frissebb változat- 
ról van szó. 

Ha végeztünk a telepítéssel, akkor a következő könyvtárak- 
nak, illetve állományoknak kell megjelenniük. 


e A /etc/init.d könyvtárban kell megjelennie a named nevű 
futtatható állománynak. E program meghívásával tud- 
juk a DNS-kiszolgálót indítani, leállítani vagy éppen új- 
ratölteni a beállításfájlokat. 

e A /etc könyvtárba kerül a named.conf állomány, amely 
a DNS-kiszolgáló alapvető beállításait tartalmazza. Erre 
az állományra nagy szükségünk lesz a továbbiak folya- 
mán is. 

e A további beállításokat, valamint a különböző zónaleíró- 
kat a /varlibínamed könyvtár alatt találjuk, illetve az álta- 
lunk létrehozott állományokat is ide célszerű elhelyezni. 


A named.conf 

A named.conf állományban tudunk beállítani minden fonto- 
sabb jellemzőt, amely DNS-kiszolgálónk futása során felme- 
rül. Ebben lehet beállítani az úgynevezett Master és Slave 
zónákat és a kiszolgáló jellemzőit, például a használt 
könyvtárakat, naplózási beállításokat és az elérhetőségi 
beállításokat. 

Kezdjük az options résszel. Az első bejegyzés a directory, 
itt adhatjuk meg, hogy a rendszer melyik könyvtárat hasz- 
nálja a futása során. Alapértelmezettként a /var/libl/named 
van beállítva. 

A következő bejegyzés forw harders kapcsoló. Ezzel adhat- 
juk meg azoknak a DNS-kiszolgálóknak az IP-címét vagy 
csoportját (lásd később), amelyeket a hozzánk beérkező ké- 
rések kiszolgálására használni szeretnénk. Amennyiben egy 
kérés érkezik hozzánk, és nem tudjuk a címet visszafejteni, 
alapesetben a fő névkiszolgálók valamelyikéhez fogunk for- 
dulni. Ha ebben a bejegyzésben egy vagy több névkiszolgá- 
lót adunk meg, először őket kérdezzük le, mielőtt magasabb 
szinthez fordulnánk. 

A forward first kapcsoló beállításával azt érjük el, hogy 

a beérkező kéréseket először külső kiszolgálóval próbáljuk 
meg feloldani, mielőtt a saját adatbázisunkhoz fordulnánk. 
A listen-on kapcsolóval be lehet állítani, hogy melyik 
helyi hálózati csatoló melyik kapuján nyújtsunk DNS-szol- 
gáltatást. 

A listen-on-ipv6 bekapcsolásával értelemszerűen a meg- 
adott hálózati csatolón fogadjuk el az IPv6-os kéréseket. 
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Az allow-guery kapcsolónál be tudjuk állítani, hogy mely 
ügyfelek futtathassanak lekérdezéseket a rendszerben. 
Alapértelmezésként bárhonnan elfogadunk kéréseket. 

A notify kapcsolóval be tudjuk állítani, hogy a naplóban 
megjelenjenek-e a kiszolgáló állapotáról szóló üzenetek. 
Sok tartomány esetén javasolt a naplózás tartományonkénti 
beállítása, ugyanis a túl sűrű naplózás nagyon leterhelheti 
a kiszolgálót. 

Az al low-transfer kapcsolóval korlátozhatjuk azt, 

hogy mely kiszolgálók kérhessék le DNS-kiszolgálónk 
zónaállományait. Ezt érdemes beállítani, hogy csak 

a szükséges kiszolgálók kapjanak ilyen jogosultságot, 
mivel ezen a felületen keresztül akár szolgáltatásmegtaga- 
dásos (Denial of Service, Do5S) támadást is lehet indítani 
a gép ellen, arról nem is beszélve, hogy nem feltétlenül 
szeretnénk a hálózatunk felépítését mindenki számára 
láthatóvá tenni. (Iartománynév bejegyzésekor a bejegyző 
szervezet ellenőrzi, hogy a bejegyzendő zóna megfelel-e 
a szabályoknak, ehhez viszont transfer jogosultságot 
kell biztosítani.) 

A logging résznél beállíthatóak a rendszer naplózással 
kapcsolatos jellemzői. Ezeket hagyhatjuk alapértéken. 
Amennyiben mégis hozzányúlunk, figyeljünk oda, hogy 
egy rossz naplózási beállítás felhizlalhatja a napló mértét, 
vagyis felesleges adatokkal töltheti fel. 

Elérkeztünk a zónarészhez. Ebben tudjuk beállítani a kü- 
lönböző kiszolgált zónák leíróinak helyét, típusát, illetve 
egyéb jellemzőket is megadhatunk, például naplózással 
kapcsolatos beálltásokat. Gyakorlatilag minden zónához 
külön-külön megadhatjuk az előbb látott options részben 
beállított értékeket. 

Egy zóna bejegyzéséhez legalább az alábbi értékek megadá- 
sa szükséges: 


zone "zóna neve" ( 
type zóna típusa; 
file zóna állomány; 


12 


lípusnak meg kell adnunk, hogy az adott zóna a kiszolgáló 
szempontjából milyen típusú. A forward zóna minden ké- 
rést egy adott kiszolgálóhoz továbbít. A hint egy különle- 
ges zóna, amely egy fő névkiszolgálóra mutat, arra az eset- 
re, ha olyan névvel találkoznánk, amit nem tudunk felolda- 
ni. A master — amúgy a leggyakrabban használt típus -— egy 
olyan zóna, amelynek a leírófájlja a kiszolgálón található. 

A slave egy olyan típus, amit ugyan ismerünk, de a zóna 
leírójának szerkesztése nem a mi feladatunk, készen kapjuk 
őket a zóna elsődleges (master) kiszolgálójától. 

Az állomány változó értékének azt a fájlt kell megadnunk 

a named munkakönyvtárán belül, amelyik az adott zóna le- 
írását tartalmazza. 

Ennek a fenti két kapcsolón kívül további korlátozó kapcso- 
lók állíthatók be, mint például az al low-guery és az al low- 
transfer, ezekről már esett szó, valamint az al low-update. 
Ez utóbbinál megadott gépek vagy gépek csoportja jogosult 
dinamikus bejegyzéseket elhelyezni a zónaleíró állomány- 
ban. Erre a dinamikus frissítésre szükségünk lehet, 
amennyiben például egy windowsos Active Directory DNS 
kiszolgálását szeretnénk ellátni. 
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com] [dr9 ] [ret] [edu] [me] [mi] [d] [u] [at] [de] méne 
omain 
Second 
Level 
Domain 


Még egy fontos csoport létezik, amit a named.conf állomá- 
nyon belül létre tudunk hozni. Amennyiben több IP-címet 
szeretnénk egy csoportban kezelni, például az al low- 
transfer kapcsolónál, úgynevezett gyűjtőket (access 
control statement, acl) hozhatunk létre. Egy ilyen acl alá 
több IP-t is megnevezhetünk, így a gyűjtőnévre való hivat- 
kozás során az összes gyűjtőben lévő gépre hivatkozunk. 
Az alábbi példával a Budapesti Műszaki Egyetem DNS- 


kiszolgálóit tettük egy csoportba. 


ac] BME-DNS ( 
152.66.115.1; 
152.66.116.1; 
ha 


Ezután egy zóna beállításain belül nyugodtan használhat- 
juk a következő beállítást: 


allow-transfer í BME-DNS; j; 
Ezzel a BME DNS-kiszolgálóit jogosítjuk fel zónaátvitelre. 


Zónaleírók szerkesztése 

Ha végeztünk a named.conf beállításával, akkor itt az ideje 
létrehozni a megfelelő zónaleírókat. Ezeket az állományo- 
kat célszerű a /var/libl/named könyvtárban alkönyvtárakba 
elhelyezni. 

A zónaállományok legfontosabb bejegyzéseit, úgynevezett 
Resource Recordjait (RR) a következőkben foglalhatjuk 
össze. 

Az első Resource Record a SOA (Start of Authority). A SO0A 
olyan fontos adatokat tartalmaz a zónáról, mint a zóna sor- 
száma, frissítési ideje, lejárati ideje, DNS-címe, illetve a kar- 
bantartó elektronikus levélcíme. 


Lássunk egy példát! 
example.com. 800 IN SOA ns.example. com. 
info.example.com. 1234 3600 900 604800 1800 


Példánkban az example.com a SOA rekordja, amit a DNS- 
kiszolgálók 800 másodpercig tartanak a gyorstárban. Az 
ns.example.com a DNS-kiszolgálója, az inforwdexample.com-ra 
lehet a tartománnyal kapcsolatban levelet írni. Az 1234 

a sorszáma, 3600 másodpercenként frissít, 900 másodpercen- 
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ként történik újrapróbálkozás, ha nem sikerül a művelet, 
604 800 másodperc után jár le a bejegyzés érvényessége, va- 
lamit legkevesebb 1800 másodpercig érvényes a bejegyzés. 
Miután létrehoztuk a S0A-t, lehetőségünk nyílik a többi re- 
kordot meghatározni. Általában a következő rekordok szok- 
tak szerepelni egy zónaleírásban. 


NS (Name Server) 
Ezzel lehet meghatározni a névkiszolgálót. Egy ilyen re- 
kordra mindenképpen szükség van. Például: 


example. com IN NS ns . example . com 


MX (Mail Exchanger) 

Ezzel a bejegyzéssel tudunk a tartományhoz levélkiszolgá- 
lót rendelni. Amennyiben rendelkezünk az example.com 
tartománnyal, és benne a mail.example.com nevű kiszol- 
gálóval, akkor egyfelől küldhetünk levelet az 
infordmail.example.com címre, hiszen pontosan megadtuk, 
melyik gép melyik felhasználójáról van szó. Ha viszont az 
infordexample.com címre szeretnénk levelet küldeni, szük- 
ségünk lesz az MX bejegyzésre, mert ez mondja meg, me- 
lyik az alapértelmezett levélkiszolgáló a tartományban. 
Létre kell hozunk a következő bejegyzést: 

example. com IN MX 10 mai I . example . com. 
Ebben a 10 a kiszolgáló súlyát jelöli, így lehetőségünk nyílik 
elsőbbségi sorrendet felállítani a különböző kiszolgálók kö- 
zött, ezzel biztosítjuk a megfelelő levelezési szolgáltatást 
üzemzavar esetére is. 


A (Address) 

Ez a rekord használatos egy adott névhez IP-cím hozzáren- 
delésére. 

ww 5 PIN A  123.456.789.001 

CNAME (Canonical Name) 

Ezzel a bejegyzéssel egy adott A rekorddal társított névhez 
további neveket lehet rendelni. Megtehetjük, hogy az előbb 
létrehoz www.example.com kiszolgálóhoz hozzárendeljük 
az ftp.example.com nevet a következő módon: 
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ftp IN — CNAME www 
Ugyanakkor azt is megtehetjük, hogy az ftp.pelda.hu kiszol- 
gálóhoz létesítünk egy bejegyzést ftp.examle.com néven: 
ftp IN CNAME ftp.pelda.hu. 

Itt hívnám fel a figyelmet arra, hogy amennyiben teljes tar- 
tományneveket használunk, ne felejtsük le a cím végéről 

a pontot. Az utolsó pont ugyanis a fő (root) szintet jelöli 

a bejegyzésben. 

A CNAME-bejegyzéssel lehetőségünk van rá, hogy dina- 
mikus IP-címmel rendelkező géphez saját magunk által 
bejegyzett tartománynevet regisztráljunk. 

Mindössze valamelyik dinamikus DNS-szolgáltatónál — pél- 
dául a 5 http:/www.dyndns.org - szükséges készíteni egy 
bejegyzést, majd az így kapott tartománynévre kell egy 
CNAME-bejegyzést csinálni a saját DNS-kiszolgálónkban. 


AAAA (Address for IPv6) 

Ugyanazt a feladatot tölti be, mint az IPv4 esetén az 

A, azzal a különbséggel, hogy itt IPv6-os IP-címet kell 
megadni. 

Egy zóna leírásához használhatók további rekordok is, 
ezekkel további adatokat közölhetünk a rendszerről, pél- 
dául a kiszolgálógép felépítését, a használt operációs rend- 
szert vagy akár a földrajzi elhelyezkedést. Utóbbi jópofa 
dolog, ha grafikus traceroute programok számára fellel- 
hetővé szeretnénk tenni a kiszolgálót. Paranoiás rendszer- 
gazdák ne töltsék ki ezeket a rekordokat. 


A DNS frissítése 


Amennyiben változás áll be zónában, akkor módosítani 
kell a megfelelő zónaállományt is. De nem elég, ha módo- 
sítjuk a megváltozott bejegyzést, hanem az adott zónához 
tartozó sorszámot is meg kell növelnünk legalább eggyel. 
Miután a zóna leíróját mentettük, a /etc/init.d/named 
reload paranccsal frissíthetjük a kiszolgálót. Innentől fog- 
va pár percen, órán belül elterjed a világban a módosított 
bejegyzés. 


Összegzés 

A DNS-kiszolgálók felépítéséről, beállításáról rengeteg út- 
mutatást találhatunk az interneten. Erre legjobb kiindulás 
a Google, vagy valamelyik másik nagy kereső. Maga 

a DNS-szolgáltatás többet is rejt magában puszta név- és 
címfeloldásnál, erre jó példa a grafikus útkereső programok 
által nyújtott szolgáltatás, de DNS-en keresztül akár tanú- 
sítvány- vagy kulcskiosztást is készthetünk. 

A lehetőség adott, mindenki nyugodtan ássa bele magát. 
Jelen cikk terjedelme sajnos nem tett lehetővé bővebb is- 
mertetést, de arra mindenképpen elég volt, hogy áttekintő 
képet adjon a DNS elvi és gyakorlati működéséről. 


Illés Viktor (viktor2ei.hu) 

23 éves, a BME műszaki informatikus szakának 
hallgatója, mellette weblapokkal, linuxos 

és windowsos rendszerekkel foglalkozik. 
Szabadidejét legszívesebben a szabadban tölti, 
teniszezik és kerékpározik. 
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Számítógép hálózatok (6. rész) 


A távbeszélő rendszerek, modemek, az adatkapcsolati réteg és protokolljaik. 


távbeszélő rendszer hasznos dolog, főként azért, 
AA mert jó a kiépítettsége. Ha azonban számítógépe- 

inkkel ezen keresztül szeretnénk kapcsolatot tarta- 
ni egymással, modem is szükséges hozzá. Miután lerántottuk 
a leplet e misztikus szerkezetek működéséről, befejezzük a fi- 
zikai réteggel való foglalkozást, és egy szinttel feljebb lépünk. 
A telefonhálózatot annak idején az emberi beszéd továbbí- 
tására találták ki. Mivel 1876-ban még nem hogy számító- 
gép, de digitális technika sem volt, ezért a telefonhálózatok 
analóg rendszerként működtek, azaz a hangot a feszültség 
(vagy egyéb más fizikai jellemző) időbeli változtatásával to- 
vábbították. A számítógépek sajnos nem tudnak ilyen mó- 
don kapcsolatot tartani egymással, ugyanis az átviteli köze- 
gek korántsem tökéletesek. Ez azt jelenti, hogy az analóg jel 
útközben megváltozik, azaz nem fog megegyezni azzal, 
amit a forrás küldött. Digitális adatátvitelkor csupán két jel- 
szintet használunk, amelyeket akkor is meg lehet különböz- 
tetni, ha a jelet viszonylag nagy torzulás éri. 
A digitális hálózatok sok szempontból előnyösebbek az ana- 
lógokénál (lásd előző rész), ezért a telefontársaságok is kezd- 
tek áttérni a digitális átvitelre. Ma már a legtöbb helyen 
a tönkök között digitális vonalakat építenek ki. 
A távbeszélő hálózat gerince tehát hiába digitális, ha rajta ke- 
resztül két számítógép szeretne kapcsolatot tartani, szükség 
lesz egy olyan szerkezetre, amely a számítógépről érkező di- 
gitális adatokat analóg jellé alakítja (és ugyanezt fordítva). 


A modem 

Ez az eszköz a modulátor-demodulátor, vagy közismer- 
tebb nevén a modem. Fontos, hogy a modem nem egy 
analóg-digitális, illetve digitális-analóg átalakító. Valójában 
a bemenetre érkező digitális jelek alapján modulál egy az- 
zal megfelelő analóg jelet, illetve a beérkező analóg jeleket 
demodulálja. 

Vajon mit is csinál a moduláló? Az analóg jeleket nehéz ke- 
zelni, mivel frekvenciájuk, amplitúdójuk és nem utolsó sor- 
ban fázisszögeik is vannak, és mindezeket az adatok továb- 
bítására is ftelhasználhatjuk. Digitális jelet úgy továbbítha- 
tunk, ha az adott digitális jel függvényében megváltoztat- 
juk az analóg jel valamelyik jellemzőjét. Ezt a tevékenysé- 
get modulációnak nevezzük. 

Az 1. ábrán példát láthatunk különböző modulációs eljárá- 
sokra. A felső sorban a négyszöghullámot, azaz magát a di- 
gitális jelet látjuk. A második sorban láthatjuk, hogy a jel 
,átesett" egy amplitúdó-moduláción, ennek során az analóg 
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jel amplitúdóját változtatgatták a digitális jelnek megfele- 
lően. Ebben az adat az amplitúdó nagyságában rejlik. 
Külön értéket rendeltek a 0-s, és külön értéket az 1-es 
digitális jelhez. 

A frekvencia-modulációnál a frekvenciát, a fázisszög-modu- 
lációnál pedig értelemszerűen a fázisszöget változtatgatjuk. 
A modemek többféle modulációs eljárást alkalmaznak, így 
egyszerre több bitet képesek átküldeni. Például úgy, hogy 

a 0, 90, 180, 270 fokos fázisokhoz két különböző amplitúdót 
rendelnek (amplitúdó alatt most az origótól vett távolságot 
érjük). Ez azt jelenti, hogy 8 kombinációban modulálhatunk 
hullámokat, azaz egy jelváltással 3 bitet vihetünk át. 

A 2. ábrán egy kicsit jobb modulációs sémát vehetünk szem- 
ügyre. Itt 16 különböző amplitúdójú és fázisú értéket hasz- 
nálhatunk, azaz már 4 bitet is átvihetünk jelváltásonként. 
Ezt kvadratúra amplitúdó-modulációnak nevezzük, és ezt 
alkalmazták a 9600 bit/5-os sebességű modemek is. 

A 2. ábrához hasonlóakat amplitúdófázis-diagramoknak 
vagy csillagkép mintázatoknak nevezzük. Minden modem 
rendelkezik egy ilyen mintázattal, és általában csak 

a megegyező mintázatú modemek képesek egymással 
kapcsolatba lépni. (Habár a gyorsabb modemek tudják 
emulálni a náluk lassabbakat). A 3. ábrán a V.32 bis-nek ne- 
vezett szabványt láthatjuk, ezt használják a 14 400 bit/s-os 
modemek is. 

A 3. ábrán szemmel láthatóan sokkalta több pont helyezke- 
dik el, mint a másodikon. Amikor ilyen sok pontot tartamaz 
a csillagkép mintázat, akkor elég egy nagyon pici Zaj, és 
máris fennáll az átviteli hiba veszélye. Ráadásul egyszerre 6 
bitet kapunk hibásan, mivel ennyi bitet tudunk átvinni jel- 
váltásonként. A gyorsabb modemeknél a helyzet sokkal sú- 
lyosabb lehet, ezért a zajszint csökkentése érdekében a ren- 
delkezésre álló 3000 Hz-es sávszélességet felbontják 512 





keskeny csatornára. Ha egy csatorna túlságosan zajossá 
lesz, akkor egyszerűen ki kell iktatni. Az ilyen megoldások 
azt feltételezik, hogy a modem maga is processzorral ren- 
delkezik, így nemcsak a sebességüket, de árukat tekintve is 
magasabb kategóriába tartoznak. 

A mai modemek már maguk is tartalmaznak hibajavító 

és tömörítő szolgáltatásokat, ezáltal nem kell módosítani 

a meglévő programokat nagyobb sebesség elérése érdeké- 
ben. A tömörítés alapfeltétele a hibajavítás, ezért általá- 
ban ezt a két feladatot szokás foglalni. A legnépszerűbb 
ilyen szabványok a Microcom által kifejlesztett MNP és 

a VAZbis. 

Érdekes, ám a modemek életét megkeserítő jelenség a vissz- 
hanghatás. Az elektromágneses hullámok is visszaverőd- 
nek. Ilyesmi történik például akkor is, mikor telefonálás 
közben kis késleltetéssel saját hangukat halljuk vissza. 

A hullámok ugyanis visszaverődnek az előfizetői hurok le- 
zárásánál. A visszhanghatás igazából csak akkor érzékelhe- 
tő igazán, ha nagy távolságra van tőlünk, akivel beszélge- 
tünk. Ha ugyanis kicsi a távolság, akkor a visszaverődő jel 
hamarabb visszaér hozzánk, mint észrevennénk. 

A gond valójában nem a jelenséggel, hanem az őket csilla- 
pítani próbáló visszhang-elnyomókkal van. Ugyanis sok 
embert zavar, ha telefonálás közben saját hangját hallja 
vissza, ezért a telefontásaságok a 2000 km-nél hosszabb vo- 
nalakra visszhang-elnyomókat telepítettek. Ez egy olyan 
szerkezet, amely képes érzékelni, ha az egyik irányból em- 
beri hang érkezik. Ilyenkor nem engedi át a másik irányból 
érkező jeleket, ezáltal megszűnik a visszhanghatás. Amikor 
az egyik fél befejezte a mondandóját, és a másik fél veszi át 
a szót, akkor a visszhang-elnyomó irányt vált. 

Az lehet, hogy magunkat már nem halljuk a telefonban, 

de ezzel duplex átviteli kísérleteinket is keresztülhúzták. 

A duplex átvitel azt jelenti, hogy adatokat mindkét irányba 
egyszerre továbbíthatunk, például olyan módon, hogy a két 
irány különböző frekvenciatartományt használ. Ha vissz- 
hang-elnyomót telepítettek a rendszerbe, akkor csak fél- 
duplex átvitel oldható meg, ami olyan mint az egypályás 
vasúti sín: egy időben csak az egyik irányba mehetnek rajta 
az adatok. 

Sok országban ezért úgy módosították a visszhang-elnyo- 
mókat, hogyha tisztán 2100 Hz-es hangot hallanak, akkor 
maguktól kikapcsolnak. De jelenleg nagyon kevés helyen 
találunk ilyet, ugyanis a telefontársaságok attól félnek, hogy 
a felhasználók így megzavarhatják a rendszer működését. 
A visszhang-elnyomók helyett inkább visszhangtörőket 
használnak, amelyek megbecsülik a visszhang nagyságát, 
és az átmenő jelből , levonják" . 
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Külső vagy belső? 

A modemeket két alapvető csoportba foglalhatjuk. Az első 
a külső modemek családja, ezeket a szabványos soros ka- 
pun keresztül kapcsolhatjuk a számítógéphez. A modem és 
a számítógép között az átvitel digitális módon zajlik. Ennek 
módját az RS-232-C nevű szabvány rögzíti, mely egy 25 tűs 
csatlakozót ad meg. Az összes tűhöz tartozik egy szolgálta- 
tás, de valójában mindenhol csak 9 kerül megvalósításra. 

A legtöbb esetben a többi tűt el is hagyják. A logikai 0-t a -3 
V -— -15 V tartományba eső feszültségek, míg a logikai 1-et 

a 13 V és 115 V közötti feszültségek jelentik. Egy mode- 
met és egy számítógépet összekötő RS-232-es kábel legna- 
gyobb hossza 15 méter lehet, és nem igazán érhetünk el 
rajta 20 kb/s-nál nagyobb sebességet. 

Nézzük, miként is zajlik az adatátvitel az RS-232 szabvány 
szerint. Mindegyik tű egy-egy feladatot lát el, például vala- 
mit jelez. A 20-as tű azt jelzi, hogy a számítógép be van kap- 
csolva. A modem készenlétét a 6-os tű jelzi. Például, ha 

a számítógép adatot kíván küldeni a modemnek, akkor akti- 
válódik az adáskérés jel, erre a modem az adásra kész jellel 
válaszol. Ezután megkezdődik a 2-es tűn az adatok vétele. 
Látható, hogy ez nem egy túlzottan bonyolult protokoll. 

Két számítógépet összeköthetünk az RS-232-C csatolóján, 
azaz a soros kapujukon keresztül. Ilyenkor egy nullmodem- 
kábelre van szükség. 

A külső modemek külön lyukat igényelnek a konnektor- 
ban, ráadásul az asztalon is helyet foglalnak, ezért idővel 
megjelentek az úgynevezett belső modemek, amelyek ISA 
vagy PCI csatlakozófelülettel bíró kártyák. Az ilyen mode- 
mek vezérlői sokkalta bonyolultabbak, mivel nemcsak a ha- 
gyományos modemfeladatokat kell megvalósítaniuk, ha- 
nem például a csatlakozófelület kezelését is. 

Az ilyen vezérlő nagyon drága, a piacon pedig éles verseny 
folyt, így a gyártók arra törekedtek, hogy az ő termékük le- 
gyen a legolcsóbb a piacon. A költségeket úgy lehetett csök- 
kenteni, hogy a vezérlőkre csak a legalapvetőbb feladatokat 
bízták, a többit a processzorral, azaz programból megvaló- 
sított módon valósították meg. Nagy hátránya az ilyen esz- 
közöknek, hogy a megfelelő kezelőprogram nélkül sem- 
mit sem érnek. Ráadásul ezeket a programokat először 
csak Windowsra készítették el, így más rendszer (például 
Linux) alatt használhatatlanok voltak. Ezért rájuk aggatták 
a WinModem nevet. 


Adatkapcsolati réteg 

Legyen most már elég a fizikai rétegből és a műszaki 
nehézségek körbejárásából. Lépjünk egy szinttel feljebb 
és nézzük meg, miként is működik az adatkapcsolati ré- 
teg, amelynek nincs más feladata, mint a megbízható és 
hatékony kapcsolat létrehozása két szomszédos számító- 
gép között. A ,szomszédos" szó azt sejteti, hogy a két 
masina egymáshoz elég közel, például egy közös szobá- 
ban helyezekedik el és vezetékkel össze vannak kötve. 
Valójában nem az a fontos, hogy egy szobában vannak-e, 
illetve hány vezetékkel kapcsolódnak egymáshoz. Az 
sem baj, ha két különböző földrészen találhatók és tele- 
fonhálózaton keresztül, modemek segítségével tartják 

a kapcsolatot. A hangsúly azon van, hogy a kapcsolattar- 
tás csatornája ,vezetékszerű", azaz minden bit a küldés 
sorrendjében érkezik meg. 
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Az egyik gép egymás után küldi a biteket, a másik fogadja 
őket, és nem fordulhat elő olyan eset, hogy egy bit meg- 
előzzön egy másikat. Ez a világ legegyszerűbb protokollja. 
Vajon miért kell foglalkoznunk ezzel? Igazából nem lenne 
semmi gond, és egyből ugorhatnánk is a hálózati rétegre, 
ha minden tökéletes lenne: az adatok nem vesznének el, 
nem lenne az adatátviteli sebességnek korlátja, minden bi- 
tet késleltetés nélkül tudnánk küldeni, és végül de nem 
utolsó sorban minden számítógép megegyező sebességgel 
dolgozna. De sajnos a dogok nem ilyen egyszerűek. 

Mivel az adatokat csak véges sebességgel tudjuk továbbíta- 
ni, és nem nulla késleltetéssel lehet küldeni biteket, komoly 
meggondolásra kényszerít bennünket, ha valóban hatékony 
hálózatot szeretnénk létrehozni. Arról nem is beszélve, 
hogy rendkívül kellemetlen, ha a forrás gyorsabban küldi 
az adatokat, mint ahogy azt a vevő gép feldolgoni képes. 
Az átviteli hibák is gondot okozhatnak, főleg, ha nem tud- 
juk felismerni és kijavítani őket. Ezeket a felsőbb rétegekre 
is bízhatjuk, de ha túl sok van belőlük (mert mondjuk, 
rendkívül Zajos a csatorna), teljesen használhatatlanná vál- 
na hálózatunk, hiszen lehet, hogy csupán egy bájtot kellene 
újra küldeni, és nem az egész 1 KB-os csomagot. 


Az adatkapcsolati réteg szolgáltatásai 

Sorozatunk legeslegelső részében már volt róla szó, hogy 
minden réteg a felette levőnek végez el bizonyos feladato- 
kat. Ezért minden réteg rendelkezik egy jól meghatározott 
csatolófelülettel, a felsőbb réteg ezen keresztül tartja a kap- 
csolatot vele. 

Sok hálózati megvalósítás nem tesz különbséget bizonyos 
rétegek között, például az első három réteg gyakran egy 
helyen, a gép belsejében található. Mi azonban azt mond- 
tuk, olyan módon képzeljük el a dolgokat, hogy minden 
réteg egy teljesen különálló részt alkot, például mindegyik 
egy-egy folyamat, amelyek egymással párhuzamosan fut- 
nak. Ez a szemlélet sokkal könnyebben átlálthatóvá teszi 

a hálózatok működését. 

Azt se felejtsük el, hogy minden réteg csak egymással áll 
kapcsolatban, vagyis az A gépen futó adatkapcsolatiréteg- 
folyamat nem fog soha kapcsolatba lépni a B gép hálózati 
rétegével. Másik fontos dolog, hogy a rétegek sosem foglal- 
koznak azzal, hogy az alattuk levő réteg mit csinál. Az adat- 
kapcsolati protokoll tehát nem fog azzal törődni, hogy az 
adatok milyen csatornán is jutnak át a másik géphez. Ő 
csak annyit tud, hogy az általa elküldött bitsorozat a másik 
gépen - a küldés sorrendjében — meg fog jelenni. 

Ennek fényében nézzük meg, milyen szolgálatásokat is 
nyújt a hálózati rétegnek. Az, hogy melyek ezek, rendszer- 
ről rendszerre változik, de három általános szolgáltatást 
mindenhol megtalálhatunk: nyugtázatlan összeköttetés nél- 
küli szolgálat, nyugtázott összeköttetés nélküli szolgálat, 
nyugtázott összeköttetés alapú szolgálat. 

Ezek közül az első a legegyszerűbb szolgáltatás. Itt tulaj- 
donképpen nincs másról szó, mint két gép úgy küld egy- 
másnak kereteket, hogy nem vár semmiféle visszajelzést. 
Nem foglalkoznak így sem a kapcsolat felállításával, sem 
annak lebontásával. Ennek egyszerű a következménye, 
hogyha egy keret a vonalon fellépő zaj miatt megsérül, 
esetleg el is vész, a forrás erről sosem fog értesülni, és a sé- 
rült rész ismételt küldésére sincs mód. Egyértelmű, hogy ez 
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a fajta összeköttetés csak nagyon jó minőségű csatorna ese- 
tén használható, amelyen viszonylag kevés a hibaarány. 

Ha kicsi a hibaarány, elegendő a felső rétegekben elvégezni 
a hibakezelést. 

Ezt a fajta összeköttetést érdemes használnunk akkor is, 
amikor inkább az a fontos, hogy az adatok ne késsenek, 
minthogy hibátlanul érkezzenek, például a beszéd- vagy 
videoátvitelnél. Ha akadozik az átvitel, a műsor élvezhetet- 
lenebb, mintha egy-egy képkocka hibásan érkezik át. 

Ennél kicsit megbízhatóbb szolgálat a nyugtázott összeköt- 
tetés nélküli szolgálat. Itt már a megérkezett kereteket 
nyugtázni lehet, így a forrás értesülhet róla, hogy sikeresen 
célba értek-e az általa küldött adatok. Ha egy nyugta nem 
érkezik meg adott időn belül, akkor a kérdéses keretet újra 
el kell küldeni. 

Nagyon-nagyon fontos, hogy az adatkapcsolati rétegnek 
valójában nem lenne feladata a nyugtázás. Igazából nem 
követeli meg tőle sem az OSI, sem egyéb más szabvány. 

Az egész csak a hatékonyság szempontjából hasznos. 

A helyi hálózatokon a gépek üvegszálas vagy koaxiális ká- 
belekkel vannak összekötve egymással, ezért nagyrészt 

a nyugtázatlan összeköttetés nélküli szolgálatot választják. 
Ha viszont vezeték nélküli eszközöket használunk, a nyug- 
tázott összeköttetés nélküli szolgálatot érdemes alkalmazni. 
Létezik egy harmadik szolgálat is, mégpedig az összekötte- 
tés alapú. Az összeköttetés alapú azt jelenti, hogy a forrás- 
és célgép az adatcsere megkezdésekor felépítenek egy kap- 
csolatot. Amikor ez a kapcsolat létrejön, az adatkapcsolati 
réteg felelősséget vállal azért, hogy minden elküldött keret 
megérkezik, de pontosan csak egyszer. A nyugtázatlan 
összeköttetés nélküli szolgálatnál elképzelhető, hogy egy- 
egy keret elvész. A nyugtázott, ám összeköttetés nélküli 
szolgálatnál az elveszett keret ugyan pótlódik, de a nyugta 
nem, így ha az vész el, akkor egy keret akár kétszer vagy 
többször is megérkezhet. Az összeköttetés alapú szolgálat 
esetében minden keret számot kap, és az összes keret a kül- 
dés sorrendjében fog megérkezni. 

Látni fogjuk, hogy az összeköttetés alapú kapcsolat megvaló- 
sítása nem egyszerű. Az ilyen átvitelek mindig három részre 
bonthatók: a kapcsolat felépítése, a tényleges adattovábbítás 
és a kapcsolat lebontása. Az elsőben a kezdő értékek iniciali- 
zálódnak, ezek szükségesek hozzá, hogy a fent leírtakat be- 
tarthassuk. Ehhez viszonylag sok változót és számlálót szük- 
séges alkalmaznunk, amelyek erőforrásokat igényelnek, és 

a kapcsolat lebontásakor fel kell szabadítanunk őket. 

Ezt a szolgálatot gyakran használják a forgalomirányításért 
felelős kódok, ha nem akarnak foglalkozni azzal a lehetőség- 
gel, hogy esetleg az általuk küldött csomag valahol elveszhet. 
Írásomban röviden összefoglaltam, milyen szolgáltatásokat 
kell nyújtania az adatkapcsolati rétegnek a hálózati réteg fe- 
lé. A következő részben a megvalósítás kérdéseit taglaljuk, 
valamint szót ejtünk a keretezésről, a hibajavításról, illetve 
a forgalomszabályozásról is. 


Garzó András (garzoandointerware.hu) 

Körülbelül három éve foglalkozik Linux- és más Unix-rendsze- 
rekkel. Legjobban az operációs rendszerek lelkivilága érdekli, 
de nyitott egyéniség. Kedvenc étele a palacsinta, és van egy 
Richard nevű macskája. Minden észrevételt, megjegyzést, 
levelet szívesen fogad. 


EZGallery 


Itt egy választható megoldás arra az 
esetre, ha olyan kiszolgálón szeret- 
nénk elhelyezni a galériánkat, ahol 
nincs PHP-támogatás. Az EZGallery 
egy olyan alkalmazás, amelynek segít- 
ségével előre összeállíthatunk egy 
galériát: nagyjából ugyanazokat a 
műveleteket végezhetjük el vele, mint 
a Ihe Gallery nevű program segítsé- 
gével, de mindebből semmit nem 
veszünk addig észre, amíg azt nem 
mondjuk a programnak, hogy hozzon 
létre állandó (statikus) HIML-oldala- 
kat, felépítve ezzel a galériát. Ha ez 
megvolna, már csak el kell helyezni 
egy kiszolgálón a kész weboldalt. 

2 http:/friant.org/spigot 


OSRAIDS — Online szolyáltatás- 
rögzítő, számlázó és dokumentáló 
rendszer 


Ha kisvállalkozásod elsősorban szol- 
gáltatásokkal foglalkozik, és szeretnéd 
nyilvántartani, hogy egy-egy ügyféllel 
vagy tervezettel mennyit foglalkoztál, 
majd a számlát ennek alapján szeret- 
néd megírni, akkor számodra az 
OSRAIDS nagy segítséget jelenthet. 
Neve megtévesztő, nem számlázó- 
programról van szó. Sokkal inkább 
időnyilvántartó rendszerről beszél- 
hetünk, amellyel számlázni is lehet az 
ügyfeleknek, s amely a legtöbb kis- 
vállalkozásnál biztosan kiváló meg- 
oldásnak bizonyul. Az FPDF csomag 
telepítését követően PDF állományok 
készítésére is mód nyílik. Futtatásához 
szükséges: PHP támogatással ellátott 
webkiszolgáló, PHP MySOL-támoga- 
tással, MySOL, FPDF (elhagyható) és 
webböngésző. 

2 http://lathama.org/osraids 


SMB Web Client 

Eme kis program segítségével grafiku- 
san böngészhetünk a helyi hálózato- 
kon elérhető windowsos (SMB) meg- 
osztások között. Az alkalmazás igazá- 
ból egyetlen PHP parancsfájlból áll, 
amely a helyi gépen található 
smbclient csomag részeként elérhető 
programokat használja, s a kimene- 
tükből weboldalt készít. Nekünk nincs 
más dolgunk, mint a letöltött PHP 
parancsfájlt a webkiszolgálónkkal 
megjeleníteni, s máris kezdődhet 

a fájlböngészés. 

2 http:/www.nivel0.net/SmbWebcClient 


www.linuxvilag.hu 


The Gallery 


Nevéből sem nehéz kitalálni, hogy 
ezúttal mi akadt az utunkba: egy 
képgaléria program, amely arra 
hivatott, hogy számítógépen tárolt 
képeink elérhetők legyenek a weben. 
A programhoz tehát szükség van egy 
webkiszolgálóra. A telepítés után a 
galéria feltöltése is ezen a webfelü- 
leten lehetséges. Az alkalmazás önmű- 
ködően hozza létre az indexképeket, 
és támogatja a képek átméretezését, 
forgatását, sorba rendezését, felcímké- 
zését, és minden egyéb hasonló mű- 
veletet. Ha készen vagyunk, felhasz- 
nálói szinteket meghatározva meg- 
adhatjuk, hogy ki szerkesztheti, s 
milyen mértékben a galériát. Ezek 
után nincs más dolgunk, mint a nagy- 
érdemű elé tárni webgalériánkat. 

2 http:/gallery.sourceforge.net 





rsnapshot 

Nem egy helyi, illetve távoli biztonsá- 
gi mentéseket készítő csomagot láttam 
már, de messze ezt a legegyszerűbb 
beállítani és használni. A tárolást 
közvetlen hivatkozások segítségével 
végzi, vagyis ugyanazt a fájlt nem 
menti kétszer, amivel rengeteg helyet 
takaríthatunk meg. A mentések 
tetszőleges gyakorisággal elkészít- 
hetők, a távoli mentésekhez SSH-t 
használ. Futtatásához szükséges: Perl, 
rsync és SSH (elhagyható). 

2 http:/www.rsnapshot.org 


UMLet 3 

Egy egyszerű Java alapú UML-diagra- 
mokat rajzoló alkalmazásról van szó, 
melynek fontosságát csak az ismeri, 
aki fejlesztett már, vagy akinek sür- 
gősen le kellett adnia valamilyen UML 
témájú házi feladatot. Lehetővé teszi 
a diagramvázlatok gyors elkészítését, 
majd könnyedén menthetjük őket 
SVG, JPEG és PDF formátumokba. 
Mindezen felül még egy igen gyors 
szövegalapú felületet is kínál a fel- 
használók számára. 

2 http:/www.umlet.com 








Aewan 

Egy curses alapokra épülő, szöve- 
ges módú ASCII art szerkesztőről van 
szó, amely nagyjából ugyanazt tudja, 
mint egy XPaint, csak épp mindezt 
szövegesen, karakterekből összera- 
kott képekkel. A felhasználó a kur- 
zormozgató nyilakkal mozoghat a 
képen, és közben a billentyűk lenyo- 
másával , rajzolhat" egy karaktert. 
Párbeszédablakok állnak a felhaszná- 
lók rendelkezésére, amelyekkel meg- 
adhatja az előtér és a háttér színét, 
de ez mind semmi. A program réte- 
geket kezel, lehetővé teszi az átlátszó 
rétegek alkalmazását, ezenkívül az 
egyes rétegeket különböző képkoc- 
kákként is felhasználhatjuk, így le- 
hetőségünk van ASCII art animá- 
ciók készítésére is. A program fájlfor- 
mátuma rendkívül egyszerűen ele- 
mezhető, így gyerekjáték megjelenítőt 
írni hozzá. 

2 http:/aewan.sourceforge.net/ 


MoviX 


Egy olyan alkalmazásról van szó, 
amely multimédia-lejátszóvá alakítja 
át a gépünket. Félreértés ne essék, ez 
nem túlzás: ha a MoviX programmal 
indítjuk a gépünket, egy felhasználó- 
barát menüt kapunk, amellyel lehe- 
tőségünk nyílik mindenféle videókat, 
DVD-ket, VideoCD-ket lejátszani a 
gépünkön az MPlayer segítségével. 
Egyszóval egy önálló operációs 
rendszerrel van dolgunk, amely 
ugyan semmi komolyat nem tud a 
videolejátszáson kívül, de azt olyan 
egyszerűen teszi, hogy akár a nagy- 
papát is megtaníthatjuk a kezelésére. 
Az operációs rendszer egyébként 
teljes mértékben a memóriába töltő- 
dik, ezért még merevlemezre sincs 
szükségünk. 

2 http:/movix.sourceforge.net 


David A. Bandel 
(dbandelopananix.com) 
Jelenleg Panamában él, 
L Inux- és UnIiXx-tanács- 
adással foglalkozik. 


Komáromi Zoltán 
(komrokiskapu.hu) 

23 éves, a BME hallgatója, 
mellette PHP-programozó- 
ként dolgozik. Kedvenc 
területe a multimédia. 
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Csillogó muütyürök rendszergazdáknak? 


Ne egyszerűen csak figyeljük rendszernaplóinkat, hanem néhány grafikus 
eszközzel tegyük látványossá Is kimutatásainkat! 


udod, Francois, a Linux-rendszer felügyelete igazá- 
hi ból arról szól, hogy mennyi adattal bírunk a fel- 
ügyelt rendszerről. Ha csak arról van szó, hogy mi 
is történik a kiszolgálónkon, a túl sok adat az éppen megfe- 
lelő mennyiség. Igen, mon ami, viccelek, de rejlik némi 
igazság e kijelentésben. Minden Linux-rendszer - akár ki- 
szolgálón, akár asztali gépen fut — rendelkezik egy folyama- 
tos adatforrással, amely szünet nélkül ontja a statisztikai 
adatokat a processzor-terheltségről, a memória- és lemez- 
helyfoglalásról, és a rendszernaplók folyamatosan rögzítik 
őket. Emlékszel ugye azokra a naplófájlokra, Francois, ame- 
lyek naplózzák a levélforgalmat, az FIP- és webátviteleket, 
a szolgáltatások indítását és leállítását. Sok eseménnyel kell 
lépést tartani, ezért alapvető fontosságú, hogy ehhez meg- 
felelő eszközökkel rendelkezzünk. 
Ouoi? Úgy néz ki, mint egy tetszetős mütyürke? Nos az is, 
Francois. Senki nem mondta, hogy a rendszerünkön zajló 
folyamatok nyomon követése ne lehetne szórakoztató, az 
ízlésességről nem is beszélve. De hagyjuk most ezt abba, 
a vendégeink bármelyik percben itt lehetnek, addigra ké- 
szen kell állnunk. Mon Dieu, már meg is érkeztek! Foglalja- 
tok helyet, mindjárt küldöm Francois-t a borért. Hozd fel 
a 2000-es Chablis Les Clos-t! Vite! 
Helyezzétek magatokat kényelembe, mes amis! Mostani írá- 
som témája a rendszerfelügyelet, és tudjuk, hogy aki bármi- 
lyen számítógépet használ - legyen az akár csak egy ottho- 
ni rendszer -— a saját gépének a rendszergazdája. Ti vagytok 
a főnökök, mes amis. Olykor sokak főnöke, máskor csak 
a magatok urai. Mindnyájan tudjátok, hogy mit szoktak 
a rendszergazdákról mondani, non? Egy jó rendszergazda 
mindenről tud, és ezt folytatva azt is tudjuk, hogy minden 
tudás segítő kezet nyújt a rendszergazdai teendők elvégzé- 
séhez. Habár furcsán nézne ki egy százkezű rendszergazda, 
mégis biztos vagyok benne, hogy sokan látnák ennek elő- 
nyeit. Ennek oka a mai menü furcsasága, amelyben olyan 
grafikus eszközöket fogok bemutatni nektek, melyek 
a rendszerünkhöz adott mütyürkék segítségével hivatottak 
minket adatokkal ellátni. 
Habár a munkaasztalunkon lévő tapéta is érdekes lehet, de 
ugyanígy dinamikus alkalmazásokat is helyezhetünk a hát- 
térbe. Például képzeljünk el az asztalon egy olyan kijelzőt, 
amely a háttérben folyamatosan tájékoztat a processzor ter- 
heltségéről, a szabad lemezhelyről és a hálózati forgalom- 
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1. kép. A SuperkKaramba-motívumok hasznos információkkal szolgálnak 
és még Jól Is mutatnak 


ról. Ha ez felkeltette az érdeklődésünket, szerezzük be 
Adam Geitgey SuperKkKaramba nevű programját. A Karamba 
előtt álló super jelző esetleg olyan gondolatot ébreszthet va- 
lakiben, hogy a csomagnak létezett korábban elődje, és va- 
lóban. Az eredeti Karamba szerzője Hans Karlsson. Ha látni 
szeretnénk egy csodásan elfoglalt SuperKaramba-asztalt, 
vessünk egy pillantást az 1. képre. 

A legfrissebb forráskódot a SuperKaramba honlapjáról 
(http:/netdragon.sourceforge.net) tölthetjük le. A csomag 
lefordítása a sokak által jól ismert ötlépéses kicsomagoló— 
fordító eljárással ekképpen fest: 


tar -xzvf superkaramba-0.33.tar.gz 
cd superkaramba-0.33 

. /configure --prefix-/usr 

make 
su -c "make install" 

A csomag forráskódjának fordításához szükségünk lesz 

a Python fejlesztői programkönyvtárakra. Azok, akik szeret- 
nék magukat megkímélni ezektől a fordítási lépésektől, 

a SuperKaramba oldalon találhatnak számos rendszerválto- 
zathoz előre fordított csomagokat. Ha a SuperKaramba for- 
dítása mellett döntünk, és a KDE 3.2-es változatát használ- 


g Download ... 


hó 


3 a (HT RRR 


2. kép A SuperKkKaramba indítóképernyője 


juk, furcsa jelenséget tapasztalhatunk. Előfordulhat, hogy 
mostanáig már javításra került a hiba a forráskódban, de 

a motívumok mindig az előtérben helyezkednek el, és ily 
módon akadályozzák az egyéb aktív ablakokat. Ennek kija- 
vításához az src könyvtárban lévő karamba.cpp fájlt kell át- 
szerkesztenünk, miután a forráskódot kibontottuk. Keres- 
sük meg az alábbi sort: 


KWin: : setrType(winId() , NET: :Dock); 


Majd tegyük hatástalanná a megjegyzést jelölő kettős perjel 
segítségével az alábbi módon: 
// Kwin: :setType(winIdŐ) , NET: :Dock); 


Meg is volnánk. Fordítsuk le a forráskódot, és máris működik. 
A SuperKkKarambát a parancssorból a superkaramba pa- 
ranccsal indíthatjuk. A program a rendszeremen a KDE 
Utilities menüjében is megjelenik. A program indulásakor 
egy ablakot láthatunk, amely három lehetőség közül enged 
választani (2. kép). Mon Dieu! Francois, gyorsan hozd ide 
azt a bort és töltsd tele a poharakat. Úgy tűnik, valamilyen 
Python mégiscsak besettenkedett a kódba. 

Az Open-re kattintva nyílik lehetőségünk a már telepített 
bőrök kiválasztására. Írásom időpontjában a SuperKaramba 
honlapjának témákat kínáló oldala még nem készült el, 
ehelyett a KDE-Look.org oldalra irányította az embert. A bal 
oldali menüben a , Karamba" szót kell keresnünk. Az egyes 
motívumok (a Karamba alá írt eszközök - a ford.) különbö- 
ző tulajdonságok szerint rendezettek, ezeket a lista feletti 
fülekre kattintva választhatjuk ki. Böngészhetjük a leg- 
újabb, vagy a letöltések alapján legnépszerűbb, illetve legsi- 
kerültebb tételeket. 

Minden Karamba-motívumhoz találhatunk egy képernyő- 
képet, ezeket le is tölthetjük. Válasszunk ki egy számunkra 
megfelelőt, majd töltsük le és csomagoljuk ki a tar-csomagot 
egy megfelelő alkönyvtárba. A csomagok némelyike a tar 
és gzip, egyesek pedig a tar és bzip segítségével lettek be- 
csomagolva. Nincs szigorú szabály a motívumok helyére 
vonatkozóan, a megnyitásukat végző párbeszédablak segít- 
ségével bárhol megtalálhatjuk őket. Én egy Karamba nevű 
alkönyvtárt hoztam létre a fájlok tárolására. legyük fel, 
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3. kép Éppen a Micromon rendszerstatisztikál lebegnek az asztalunkon 


hogy Kelly a 16-os asztalnál Flavio Gargiulo Micromon ne- 
vű motívumát (3. kép) szeretné betölteni, amely Simon Ask 
Ulsnes Minimonjának egy továbbfejlesztett változata, és 
tar és gzip tömörített csomag formájában érkezik. Kelly 

a következőt tenné: 


cd -/Karamba dir 
tar -xvf 8722-micromon-1.0.tar.gz 


Ha pedig a 9-es asztalnál ülő Jon elhatározása az, hogy 
Matti Liguid Weather motívumát (4. kép) telepítse, amely 
bzip2-vel csomagolt tar-állományként érhető el, az alábbi 
parancsot használná: 


cd -/Karamba dir 

tar -xjvf lwp-1.9.tar.bz2 

Talán egy időjárás motívum nem kapcsolódik szorosan 

a rendszergazdai teendőkhöz, de neked, Jon, tetszeni fog. 
Mindenesetre további telepítési vagy fordítási lépés szük- 
ségtelen, csak ki kell csomagolni az állományokat és készen 
is vagyunk. Ezt követően már csak a telepítési könyvtárra 
kell ráállnunk és a .theme kiterjesztésű fájlt kell megkeres- 
nünk. Kattintsunk erre a fájlra majd az OK gombra. A mo- 
tívum elindul és megjelenik az asztalunkon. lovábbi mo- 
tívumok betöltéséhez sem szükséges újra kiadnunk 

a superkaramba parancsot, elegendő, ha a jobb gombbal 

a pillanatnyi motívumon kattintanunk és a megjelenő me- 
nüből az Open new theme (új motívum megnyitása) menü- 
pontot kiválasztjuk. A pillanatnyi motívumon végrehajtott 
jobb egérkattintással más lehetőségeket is elérhetünk, pél- 
dául a jelenlegi motívum vagy beállítófájljának szerkesztése 
is közéjük tartozik (5. kép). A motívumfájlok rendszerint 
könnyen olvashatóak és egyszerű módosítási lehetőséget 
kínálnak. Például a Micromon motívumot (1. kép) úgy mó- 
dosítottam, hogy a saját lemezfelosztásomat (partition) jele- 
nítse meg, ne a szerző által meghatározottakat. A könnyebb 
olvashatóság érdekében a betűméretet is megnöveltem. 
Egy motívum asztalon történő mozgatásához az ÁLT billen- 
tyű nyomva tartása mellett kattintsunk a motívumon az 
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4. kép A lLiguid Weather motívum módosítható, így bármilyen helyről 
képes időjárásjelentés készítésére 


egér bal gombjával, majd húzzuk a motívumot az asztalon 
arra a helyre, ahova tenni szeretnénk. Az elhelyezkedés 
adatai a saját könyvtárunk .superkaramba alkönyvtárában 
lévő .rc fájlban tárolódnak. Például az enyém 

a /home/marcel/.superkaramba könyvtárban található. Mie- 
lőtt valaki úgy döntene, hogy megnézi az egyik futó motí- 
vumának .rc fájlját, szólnom kell egy érdekes jelenségről. 
Az .rc fájl mindaddig üres, amíg ki nem kapcsoltuk a motí- 
vumot vagy ki nem jelentkeztünk a rendszerből. A program 
kikapcsolása nélküli kiíratás egyik módja, hogy a fájlban 
jobb egérgombbal kattintunk az éppen futó témán és kivá- 
lasztjuk a Reload theme (a motívum ismételt betöltése) 
menüpontot. 

Íme egy részlet Ryan Nickell skSeti asztali programjából, 
ez egy olyan kis motívum, amely nyomon követi 

a SEIIKohome előrehaladását. 


[config menu] 
bgImage-false 


Llinternal] 

desktop-0 
fastTransforms-true 
lockedPosition-false 


[theme] 

Vers10n-0.01 

background-bg. png 

firstTime-No 

seti. Directory-/home/marcel/setiathome/ 
widgetHeight-100 

widgetPosX-0 

widgetPosY-0 

widgetwidth-100 


Sok SuperkKaramba motívum található a világhálón. Néhány 
ezek közül a Kicker panelt helyettesíti, ezek közé tartozik 
Sven Johannsen Glass Machine-ja (amit az 1. kép alján látha- 
tunk). A Glass Machine nemcsak a Kicker lehetőségeinek 
gyors elérését teszi lehetővé, hanem az XMMS vezérlését is 
kényelmessé varázsolja. Egy kis zene segíti a rendszergazdá- 
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micromonitheme- KWrite 


File Edit View Bookmarks Tools Settings Help 


elik OO éa ue vRR B a 
$ Also, since I have only one fan in ny case (the CPU fan), there is only 
$ one fan sensor (a permanent zero looks stupid) 
ht 


$ Hope you like it... 

kj 

karamrba x-824 y-548 w-200 h-228 interval-500 locked-true 
ks 


$ Icons 

irage x-0 y-0 path-"irages/cpu.png" 
irage x-4 y-30 path-"irages/rer. png" 
irage x-7 y-60 path-"irages/net.png" 
irage x-4 y-86 path-"irages/hdd.png" 
$irage x-8 y-115 path-"irages/tire.png" 


$ CPU monitor 
text x-30 y-4 sensor-cpu formrat-"cpu: 1794 MHz / Sv" color-255,255,255 fontsize-10 interval-500 


$ Merory ronitor 
text x-30 y-28 sensor-renory forrat-"ram: $um / $tmrb" color-255,255,220 fontsize-10 
text x-30 y-38 sensor-remory forrat-"swap: $us / $tsmrb" color-255,255,220 fontsize-Ll6] 





$ Network monitor 

text x-30 y-58 sensor-network device-"ethl" forrrat-"in: $in kb/s" color-228,255,255 fontsize-10 
interval-250 

text x-30 y-68 sensor-network device-"ethl" forrat-"out: $out kb/s" color-255,220,255 
fontsize-10 interval-250 

kij 

$ Harddrive monitor 


5. kép A SuperkKaramba .theme fájljának szerkesztése 


kat munkájuk elvégzésében, s itt számos zenekezelő eszköz 
és multimédiás programocska közül válogathatunk. 

Más motívumok pusztán a szórakoztatásunkat szolgálják, 
ezek közé tartozik a Reverant2501 másodperceket is mutató 
TubeClock órája, melynek láttán az idősebb olvasók kelle- 
mes nosztalgiát érezhetnek, a fiatalabbak pedig vélhetőleg 
dögösnek fogják találni. A hasznosabb csomagok, például 

a Chip 2003 IDE (I Desktop Enhancements, azaz T asztali 
továbbfejlesztések) programja, számos eszközt kínálnak, 
amelyek közt találhatunk jegyzettömböt, rendszernapló- 
nézegetőt, lemez-, memória- és teljesítményfigyelő eszközö- 
ket. A Chip 2003 a TMon nevű szép rendszerfigyelő progra- 
mot is tartalmazza. Még jó néhány programot említhetnék, 
de már csak egyet szeretnék bemutatni: a The Karamba 
motívumot, melynek szerzője artoo. Ez a SuperKarambá- 
hoz írt GkRellm-hez hasonló figyelőprogram, amely egy 
függőleges ellenőrzőablakban mutatja az összes számunkra 
szükséges adatot. 

Ezek a SuperkKaramba motívumok mind azt szolgálják, 
hogy a rendszerünkkel kapcsolatos összes szükséges adat- 
hoz hozzájussunk és eközben a látvánnyal a szemünket 

is kényeztessék. Ha egyszer belekóstolunk e motívumok 
használatába, nem lesz nálunk jobban tájékoztatott rend- 
szergazda - bár sajnos előfordulhat, hogy ugyanezt a mun- 
kánk eredményességéről nem lehet majd elmondani. 
Megint csak tréfálok, mes amis. 

Úgy tűnik, hogy a záróra mindjárt utolér minket, Mon 
Dieu! De látom, hogy mindnyájan belefeledkeztetek a kü- 
lönböző motívumok telepítgetésébe. lalán Francois lesz 
olyan jó hozzánk, hogy amíg kísérletezgettek, utoljára tele- 
tölti a poharainkat. 

A vötre santé! Bon appétit! 


Linux Journal 2004. május, 121. szám 


Marcel Gagné (mggagneosalmar.com) 

az Ontario állambeli Mississaugában él. 

Ő a szerzője a Válts Linuxra! Búcsú a kékhaláltól 
című előkészületben lévő könyvnek. Első könyve, 
a nagy tetszést aratott Linux-rendszerfelügyelet 
(Kiskapu Kiadó). 





Blosxom 


Modulok nélkül, SOL nélkül, gond nélkül. 


akár a webkiszolgáló újraindítása nélkül! 


weblogok, más néven blogok népszerűsége sokat 
nőtt az elmúlt néhány évben. Az 1990-es évek ele- 
jén és közepén mindössze néhány ember írt blo- 
gokat, mára a bloggolás mint jelenség, uralkodó irányzattá 
lett. Népszerűsége olyan nagymértékű, hogy a New York 
limes oldalain is jelent meg e témával foglalkozó írás, mely 
a saját blogokat készítő főiskolai hallgatókra összpontosított. 
Mostanában, hogy a demokrata vezetők a figyelem közép- 
pontjában állnak, minden jelölt rendelkezik legalább egy hi- 
vatalos webloggal. A hivatásosok és a vezető politikai tudó- 
sítók saját blogokat készítettek, amelyekben nyilvántartják 

a jelöltek naplóinak állításait és többnyire elemezik is őket. 
Múlt hónapban a Zope alapú CORBEBlogot vettük szem- 
ügyre, ami rendkívül megkönnyítheti saját weblogunk el- 
készítését. lermészetesen a COREBlog használatához ren- 
delkeznünk kell egy Zope-példánnyal, továbbá az sem árt, 
ha tudjuk telepíteni és módosítani is a termékeket. Nem 
mindenkinek adatik meg az ilyen luxus, ugyanakkor a Perl 
nyelven írt CGI programok futtatását szinte minden 
webszolgáltató engedélyezi. 

Ebben a hónapban a Perl nyelven írt és CGI programként 
futtatható Blosxom (2 http:/www.blosxom.com) rendszerrel 
foglalkozunk. A Blosxomot Rael Dornfest, az O Reilly egyik 
programozója készítette. Első ízben, mint bloggolásra aligha 
alkalmas eszközről írtam a Blosxomról, feltételezve, hogy 
kis mérete arányban áll képességeivel. A Blosxom ereje 
azonban nemcsak komoly képességkészletében rejlik, ha- 
nem fő vonzereje, hogy e képességek összeválogatását és 
keverését egyaránt lehetővé teszi. 





A 


Telepítés 
Webkiszolgálók terén kicsit is jártasak számára a Blosxom 
telepítése gyerekjáték. Egyetlen, Perl nyelven írt CGI prog- 
ramot tartalmaz. Például nekem nem kellett mást tennem, 
mint a blosxom.cgi fájlt bemásolni a /usr/local/apache/cgi-bin 
könyvtárba, és már működött is minden. 
lermészetesen minden programnak szüksége van némi ál- 
lítgatásra, ez alól a Blosxom sem kivétel. Az összes beállítási 
feladatot a program elején található Perl változókon keresz- 
tül végezhetjük el. A megjegyzések az egyes változók célját 
viszonylag jól meghatározzák. Nálam a következő Blosxom 
változók átírására volt szükség: 
e $blog title: a weblog címe, ezt láthatják a felhaszná- 
lók és az RSS hírügynökségek. 
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Készítsünk nagyteljesítményű blogot, 


e  $blog description: a blog leírása, ami az RSS listában 
fog megjelenni. 

e  $datadir: a Blosxom weblog valamennyi bejegyzése 
tulajdonképpen nem más, mint a lemezen valahol elhe- 
lyezett szöveges állomány; a $datadir változó mondja 
meg, hol találjuk meg őket. 

E három elem beállítása után weblogom máris működőké- 

pes volt. 


Bejegyzések felvitele 
A Blosxom kipróbálását egy introduction.txt nevű egyszerű 
szöveges állománnyal kezdtem a $datadir könyvtárban. 


Ez egy tesztbejegyzés. 
cp:Hello!c/p:z 


Weblognak ugyan nem túl izgalmas bejegyzés, de annál ér- 
dekesebb, ahogy mindez meg fog jelenni a weblogon, ki- 
egészítve egy dátum előtaggal, a szöveg utáni időbélyeggel, 
a maradandó hivatkozással, az első sor vastagon szedve, 
mintha főcím vagy cím lenne. 

Más szavakkal, a Blosxom weblog rendszerébe új bejegy- 
zéseket felvinni egyszerűen csak annyit jelent, hogy az 
adatkönyvtárban fájlokat hozunk létre. Valamennyi, 

a $file extension változóban megadott kiterjesztésre vég- 
ződő (azaz alapértelmezés szerint .txt) állomány weblogbe- 
jegyzésnek számít. Ebből következik, hogy például az Emacs 
— végződésű mentései nem számítanak bejegyzésnek. 

Ha hozzám hasonló módon gyakran szoktuk menteni, amit 
írunk, esetleg furcsának találjuk majd, hogy weblogunk írás 
közben változik, és ezt az egész világ azonnal láthatja is. 
Amennyiben a háttérben szeretnénk dolgozni, mindaddig 
hagyjuk le a .txt kiterjesztést az állományainkról, amíg nem 
kívánjuk kiadni őket. 

Saját gépemen a Blosxomot a fő /cgi-bin könyvtárba telepí- 
tettem, így a Blosxom blogokat a http://localhost/cgi-bin/ 
blosxom.cgi címen tudom elérni. 

A Blosxom a bejegyzésekhez tartozó dátumot és időt a fájl 
létrehozási dátumából veszi. Minthogy az állományt febru- 
ár 11-én, délután négy órakor készítettem, a weblogbejegy- 
zés is ehhez az időhöz tartozik. Ez egyben azt is jelenti, 
hogy a touch parancs segítségével megváltoztathatjuk 

a bejegyzéshez tartozó dátumot: 

touch -t 200401011500 testing.txt 


2004. június 11 





e 


0 Kiskapu Kft. Minden Jog fenntartva 





0 Kiskapu Kft. Minden Jog fenntartva 


A fenti parancs a testing.txt állomány dátumát 2004. január 
1-jén három órára változtatja. (Amennyiben a testing.txt ál- 
lomány még nem létezne, létre is hozza.) Bár ez némiképp 
ellenkezik a weblogetikett szokásaival, nyilvánvalóan meg- 
oldható feladat. 

Kicsit érdekesebb, hogy ugyanezzel a paranccsal a weblog- 
bejegyzés dátumát a jövőbe is állíthatjuk. Amennyiben 
$show future entries változó értéke 1, az ilyen jövendő- 
beli dátummal rendelkező bejegyzések mindig láthatóak. 
Az alapértelmezett beállítás esetében azonban ezek a be- 
jegyzések csak akkor jelennek majd meg, amikor a valódi 
dátum megegyezik a hozzájuk rendelttel. Ez azt jelenti, 
hogy bejegyzéseinket egy adott dátumra és időpontra idő- 
zíthetjük. 


Jellemzők (flavours) 

Ha a Blosxom csak ennyit tudna nyújtani, nem lennék 
túlságosan lenyűgözve. De ha kicsit közelebbről szem- 
ügyre vesszük, kiderül, hogy rendkívüli képességekkel 
bír. Ezeket a képességeket a megjelenítő sablonoknak 
köszönheti (amelyeket brit helyesírás szerinti , falvour"- 
nak, jellemzőkészletnek nevez), valamint annak, hogy 
tetszőleges számú bővítmény (plugin) futtatására képes. 
A Blosxom rendszert e két képessége rendkívül jól bővít- 
hetővé teszi. 

A Blosxom rendszert két beépített jellemzővel kapjuk: az 
alapértelmezett HTML jellemzőkészlettel és az RSS hírügy- 
nökséghez szánt, választható RSS jellemzőkkel. Magunk 

is megtekinthetjük az RSS formátumot, ha a blog URL vé- 
gére beszúrjuk a ?"flav-—rss kiegészítést. Ha tehát egyéb- 
ként a http://localhost/cgi-bin/blosxom.cgi címen érjük el 
webnaplónkat, az RSS alakot a Attp://localhost/cgi-bin/ 
blosxom.cgi?flav-rss kifejezéssel tekinthetjük meg. Egyéb- 
ként a kért dokumentum végződésének megváltoztatásával 
is hozzáférhetünk a különféle jellemzőkészletekhez. Így 
például a http://localhost/cgi-bin/blosxom.cgi/index.rss címen 
az RSS alakot találjuk. 

A Blosxom weboldalán teljes jellemzőkészlet-tárat találunk. 
Az alapötlet nagyon egyszerű: az adatkönyvtárunkban, 

a weblogbejegyzéseink mellett készítünk egy HIML állo- 
mányt, amelyet a megváltoztatandó Blosxom-kimenet ne- 
vével azonos módon nevezünk el. 

Az állomány utótagja a módosítandó jellemzőkészlet nevé- 
vel azonos. A header.html tehát a weblog HTML jellemző- 
készletének header elemét változtatja meg, míg a date.blah 
a blah jellemzőkészlet dátummegjelenítését befolyásolja. 

A felhasználók az URL-ben megadhatják a kívánt jellemző- 
készlet név-érték-párosát (amint azt az imént is láthattuk), 
az alapértelmezett értéket pedig magában a blosxom.cgi fájl 
$default flavour változójával állíthatják be. Minthogy 

a blogbejegyzések , txt" utótagra végződnek, txt nevű jel- 
lemzőkészletünk nem lehet. 

Minden egyes jellemzőfájl apró HIML-részletet tartal- 
maz, mely az adott állományban megjelenítendő Perl- 
változónevekkel van megtűzdelve. Például a story jel- 
lemzőfájlok többek közt két értéket kapnak a $title 

és a $body változókban. (A teljes listát a Blosxom web- 
oldalán találjuk.) Ezzel a módszerrel a törzsszöveg előtt 
álló fejléceket könnyedén nagyobb méretűre és jobbra 
igazítottra lehet alakítani: 
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Az egotrip.pl 
$1!/usr/bin/per1 
use strict; 
use warnings; 
use diagnostics; 


package egotrip; 


f 1-et adunk vissza, jelezve, hogy a bővítmény 
$ aktív 


sub start 
1 

return 1; 
J 


f Kiemeli a nevemet 
sub story í( 
my ($pkg, $path, $filename, $story ref, 
$title ref, $body ref) — a ; 


$$body ref -- s]Reuvenl]cb:s:Reuvenc/b: ]g; 
1; 


Lp: 
cH1 align-"right"5$titlec-/h1i 
cbr /5 

$body 

2/Pp: 


A fenti , flavour" blogunk tartalmát változtatás nélkül he- 
lyettesíti be a $body változó helyére. Ez módszer egész 
használható, feltéve, hogy a blog szerzője ismeri a HIML 
nyelvet és a bekezdéshatárokat hajlandó kézzel begépelni. 
Ha viszont azt szeretnénk, hogy az emberek a bekezdés- 
határokat üres sorokkal jelölhessék, írásukon végig kell 
futtatniunk valamilyen programot. Szerencsére a Blosxom 
rugalmas bővítménykezelője megkönnyíti az ilyen progra- 
mok elkészítését. 


Bővítmények 

Valamennyi bővítmény egy-egy Perl program, amelyet 

a reguire függvény olvas be és hajt végre. Például 

a reguire foo.pl a foo.pl állományt nyitja meg, majd 

a benne lévő kódot végrehajtja. Általában azt szoktam ja- 
vasolni, hogy kerüljük a reguire használatát, és inkább 
az use kulcsszót alkalmazzuk, amely számos parancsot 
képes végrehajtani, többek közt a regui re utasítást is. 
Csakhogy a reguire futásidőben értékelődik ki, míg a use 
a fordítás során hajtódik végre, jelen esetben tehát sokkal 
egyszerűbb ezzel dolgoznunk. 


A Blosxom feltételezi, hogy minden állomány, amely a tet- 
szőlegesen megadható $plugin dir változó által megadott 
könyvtárban található, valóban bővítmény. A bővítménye- 
ket ábécérendben tölti be és hajtja végre, ha tehát valamely 
bővítményt hamarabb vagy később szeretnénk futtatni, elő- 
fordulhat, hogy át kell neveznünk. 

A bővítmények nem többek egy egyszerű Perl program- 
nál, amelyek egy vagy több alprogramot határoznak 

meg. Minden bővítménynek tartalmaznia kell egy start 
alprogramot, amely egyszerűen 1-et ad vissza. A Blosxom 
ennek segítségével tudja megállapítani, hogy a bővítmény 
élő-e, és készen áll-e a futásra. Számos egyéb bővítmény 
alprogram létezik, ezeket valamennyi bővítményben 
megadhatjuk, kezdve a bejegyzésektől (entries), amelyek 
bejegyzések listáját adják vissza, egészen a történetig 
(story), ennek segítségével pedig történeteink tartalmát 
módosíthatjuk. A feladatok ilyesfajta lebontásával 

a Blosxom hihetetlen mértékű kifinomult testreszabási 
lehetőséget kínál, miközben a magkód továbbra is tömör 
és hatékony marad. 

Milyen képességeket nyújthatnak a bővítmények? Úgy 
tűnik, tényleg csupán néhány kötöttség létezik. A web- 
logbejegyzések forrását, a módszert, ahogy e bejegyzéseket 
szűrjük, a bejegyzések megjelenítéséhez használt sablono- 
kat, a bejegyzéseket, illetve akár a bejegyzések tartalmát 
egyaránt megváltoztathatjuk. 

A Blosxom weboldalán rengeteg bővítményt találunk. 
Akadnak közöttük olyanok, amelyek más bővítményektől 
függenek, míg mások, például a naptár (calendar) csak ak- 
kor jelennek meg, ha a bővítményt támogató jellemzőkész- 
letet használjuk. Más bővítmények azonnal kifejtik hatásu- 
kat, egyszerűen csak be kell dobnunk őket a bővítmény- 
könyvtárunkba. 

Egyszerű példa az önmagában is használható bővítményre 
az atomfeed, amely az Atom hírügynökség-változatot támo- 
gatja. Az Atom az RSS vetélytársa, amit néhány nehézsúlyú 
bloggoló és programozó támogat, nem utolsósorban az RSS 
világában mostanában megjelent egymással versengő szab- 
ványok miatt. Amennyiben Atom-kimenetet is szeretnénk, 
nem kell mást tennünk, egyszerűen másoljuk az atomfeed 
bővítményt a bővítmény-könyvtárunkba. Saját Atom-válto- 
zatunkat a Http://localhost/cgi-bin/blosxom.csgi?flav— atom 
vagy a http://localhost/cgi-bin/blosxom.cgi/index.atom URL-re 
hivatkozva kaphatjuk meg. 


Bővítmények készítése 

Listánkon egy egotrip névre keresztelt egyszerű szűrőt talá- 
lunk, amely a nevemet annyiszor szedi ki vastagbetűvel, 
ahányszor előfordul a weblogbejegyzésben. Figyeljük meg, 
hogy a bővítménynek saját csomagot kell megadnia; ezzel 
biztosítjuk, hogy valamennyi bővítmény alprogramjai kü- 
lön névtérben maradjanak, valamint a Blosxom el tudja 
dönteni, hogy a bővítmény tartalmazza-e az adott modult. 
A tényleges munkát a story alprogramban végezzük, amit 
a Blosxom hat értékkel hív meg, a bejegyzésben felhasznál- 
ható elemek számának megfelelően. Esetünkben kizárólag 
a bejegyzés törzsének módosítására összpontosítunk, amit 
az utolsó, $body. ref nevű változóban találunk. Mint a neve 
is mutatja, a változó skalár mutató, azaz tartalmát visszahi- 
vatkozással érhetjük el, a kettős $$ (dollárjel) karakter hasz- 
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nálatával. Ezt figyelembe véve, nem lesz nagy meglepetés, 
hogy a nevem előfordulásait a következő sorral állíthatjuk 
vastag betűsre: 


$$body ref -—- sl]Reuvenl]cb:Reuvenc/b:]g; 


lermészetesen ezt a lépést kicsit kifinomultabbra is tervez- 
hetjük, például önműködő hiperhivatkozásokat illesztve 
a különféle elemekhez: 


$$body ref -—-- s] (Reuven Lerner)I 

ca href-"http://ww. lerner.co.11/"5$1c/as]g; 
$$body ref -—- s] (Linux Journal] 

ca href-"http://ww. linuxjournal . com/"5$1c/as]g; 


Valójában létezik is ilyen bővítmény; ez a közösség által 
vezetett Wikipedia hivatkozásait kezeli. Bármely szöveg, 
amelyet [Iszögletes zárójelek]] közé helyezünk önműködő- 
en hálózati referencia könyvre mutató hivatkozássá alakul. 
Figyeljük meg, hogy a jellemzőkészletek olyan HIML- 
sablonok, amelyekbe Perl-változókat helyettesíthetünk mi- 
közben a bővítmények Perl programok. E kettősség megér- 
tése a megjelenítés és a műveletek között némi időt vehet 
igénybe, de nem túl bonyolult feladat. 

Mint azt a korábbi bekezdés-elválasztó példánk is mutatja, 
semmi szükség rá, hogy újra feltaláljuk a spanyolviaszt. 
Egyszerűen csak letöltjük a megfelelő bővítményt, neveze- 
tesen a Bloxot, amely a bekezdéseket üres sorok alapján ké- 
pes elválasztani blogbejegyzéseinkben. A bővítmény aztán 
kívánság szerinti HIML-elemekkel választja el a bekezdése- 
ket. A Blox szerepel a Blosxom bővítménytárában is (lásd 

a hálózati források részt). 

Mint említettem a Blosxom valamennyi bejegyzést és jel- 
lemzőkészletet egyazon könyvtárban tárol. Ez számomra 
kicsit zavaró és méretezhetőségi kérdéseket is felvet. 

Még ha a fájlrendszerem és Perl-csomagom gond nélkül 
kezel is ennyi állományt, biztos, hogy mindig valamennyin 
keresztül szeretnék gázolni? Amikor ez valóban kezd gon- 
dot jelenteni, az entries bővítmény siethet segítségünkre, 
amely külön könyvtárakból keresi vissza az állományokat, 
s a megfelelő hozzárendeléseket továbbítja a Blosxom- 
magnak. 


Összegzés 

A Blosxom hatékony weblogkészítő eszköz; sokkal többet 
nyújt, mint első pillantásra látszik. A Blosxom tartalmaz egy 
könnyen telepíthető, játszi módon beállítható, Perl nyelvű 
CGI programot, de igazi ereje mégis abban rejlik, hogy jel- 
lemzőkészletek (flavours, megjelenítő sablonok) és bővít- 
ményeljárások megfelelő kombinációjával a megjelenítés 
tetszőleges részét lecserélhetjük. 


LimExedOÜ taal 2ŐOZ majus et 2 TESszámi 


Rewen M. Lerner (reuvenelerner.co. il) Veterán 
web, illetve adatbázis programozási tanácsadó, 
jelenleg végzős tanárhallgató az evanstoni 
Northwestern University Egyetemen, Illlinois 
államban. 


2004. június 19 


(A 68]]ÁÓ A őÍÉ 584157. Cbb.CTL  kovácsmángy 8 


0 Kiskapu Kft. Minden Jog fenntartva 


0 Kiskapu Kft. Minden Jog fenntartva 


A kis játék sem rossz játék 


Korunk számítógépei egyre fejlettebbek. A gépek erősebbek lettek, ez magával 
hozta, hogy a programok is egyre több erőforrást foglalhatnak le maguknak. 


, 


Igy történt ez a játékiparban Is. 


gyre nagyobb, csillogóbb, és 

erőforrás-igényesebb 3D-s játé- 

kok láttak napvilágot. De vajon 
mi a helyzet a kicsikkel? Ugyanis létez- 
nek kis játékok is, amelyek méretük el- 
lenére sokszor nagyobb játékélményt 
adnak, mint a drága, lenyűgöző csodák. 
Ebből szemezgettem párat, mégpedig 
annak alapján, hogy melyiket játsszák 
a legtöbben a környezetemben. 


A legnépszerűbb? 

A Frozen Bubble az egyik legnépsze- 
rűbb kis méretű linuxos játék. Számos 
ismerősöm lelkesen játszotta a környe- 
zetemben, én pedig fel nem foghattam, 
miért is vannak annyira elvarázsolva 
tőle. Nem bírtam ki sokáig, feltelepítet- 
tem én is. A mérete igazán nem nagy, 
mindössze 7 MB helyet foglal. Az apt- 
get pillanatok alatt lehúzza nekünk az 
internetről, minden valószínűség sze- 
rint a Perl-SDL csomaggal egyetemben. 
lelepítése természetesen szintén az 
apt-get segítségével történik, a letöltés 
után önműködően. A programot fel- 
használóként a frozen-bubble pa- 
ranccsal indíthatjuk. ( lermészetesen 
ikont is készíthetünk hozzá.) 

Apró, ám mégis rendkívül szórakozta- 
tó játéknak bizonyult. Engem is elva- 
rázsolt, és hóbortommá lett, hogy vé- 
gigjátszom. Nos, ez néha nem is olyan 
egyszerű feladat. A teljes játék össze- 
sen száz pályát tartalmaz, és ha igazán 
megfertőződik az ember, akár saját pá- 
lyákat is készíthet a beépített pályater- 
vezővel. A játékhangulat rendkívüli, 
és képes órákra lekötni a játékost. Fő- 
leg akkor igaz ez, ha az ember olyan 
pályára bukkan, ami igencsak megiz- 
zasztja. (Előfordult olyan is a pálya vé- 
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ge felé, amellyel majdnem két napot 
szenvedtem). lekintsük át néhány 
szolgáltatását! 

A játék támogatja az egy- és a kétsze- 
mélyes játékot. 

Utóbbiban ne korunk többjátékos 
(multiplayer) lehetőségeire tessék gon- 
dolni, hanem a régi idők páros játékára. 
Ilyenkor a feladat a következő: a képer- 
nyő osztott lesz, mindkét ablakban 
ugyanaz a pálya van felrajzolva. A fel- 
adat mindkét játékos számára ugyanaz, 
valamelyiküknek előbb kell megtisztíta- 
nia a pályát, mint a másiknak. A páros 
játék rendkívül szórakoztató. 

Szóltunk a pályaszerkesztőről is, en- 
nek segítségével új pályákat hozha- 
tunk létre, illetve módosíthatjuk a já- 
ték alapvető pályáit. lermészetesen 


ez ; 
uja 


I 


Mk 


" 


1 


I 
IN! 


199" 


MH 


9 








a program támogatja a teljes képer- 
nyős módot is, állítható a grafikai mi- 
nőség, a játékos a teljesítményét men- 
teni tudja, és beállíthatóak a játékhoz 
használt billentyűk. lermészetesen pa- 
rancssorból is indítható, melynek kap- 
csolóira a játék leírása részletesen kitér. 
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Népszerűségi csúcsdöntő 

A másik nagy népszerűségnek örven- 
dő játék, az Lbreakout. Ez egy klasszi- 
kus játék, új köpenybe bújtatva. A cél, 
hogy a pattogó golyót folyamatosan 
mozgásban tartsuk, és a kockákat le- 
bontsuk vele a pályán. Szintén rendkí- 
vüli élmény nyújt, mert játék közben 
főként az ügyességünkre kell hagyat- 
koznunk. 

A játék természetesen pontokért 
zajlik, így egyetlen pillanatig sem 
lehet lazítani. lovább növeli a játék 
variációs lehetőségét, hogy a golyó 
által eltalált kockák bónuszokat is 
tartalmazhatnak. Ez egyaránt lehet 
pont, összeg vagy tulajdonság. Pél- 
dául a képernyő láthatatlan lesz, és 
csak a golyó és a padka látható. Két- 
szer nagyobb lesz a csúszó padka, 
esetleg éppen feleakkora. A golyó 
gyorsulhat vagy lelassulhat, és még 
sorolhatnám mennyi variációs lehető- 
ség adódhat. Szinte megunhatatlan 

a játék. Magas szinteken pedig hatal- 
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mas ügyességet kívánhat megg a já- 
tékostól minden pont megszerzése. 
Ezzel természetesen nincs vége a szol- 
gáltatások hosszú sorának. 
lermészetesen ebben is találunk több- 
játékos módot, azonban - ellentétben 
a Forzen Bubble-val - ez már valóban 
hasonlít a megszokott hálózatos mód- 
hoz. Sőt saját Lbreakout2 kiszolgálót 
is indíthatunk a játékosok fogadására. 
Mindehhez rengeteg beállítási lehető- 
ségünk van, a beépített súgó pedig se- 
gítőkész bármiről is legyen szó. lováb- 
bi (számomra igen meglepő) érdekes- 
ség, hogy a játék támogatja a bőröket 
(skin) is. Ennek köszönhetően cserél- 
gethetjük a kinézetet, vagy újat is 
meghatározhatunk a játékos számára. 
Számtalan, közel húsz kinézet közül 
válogathatunk, és bizony olykor nem 
tudtam eldönteni, melyik a szebb, hi- 
szen a többségük remekül fest. 

A játékmenet is remekül méretezhető, 
például a bónuszok száma és az alap- 
értelmezett golyó sebessége is megad- 
ható. Ha nem lennénk tisztában vele 
mit is jelentenek a játékban előkerülő 
szimbólumok, a főmenü guik help 
pontjában erről is részletes leírást talá- 
lunk. Egyetlen észrevételem van mind- 
össze a játék kapcsán: az egér haszná- 
lata szinte felesleges. Adott ugyan az 
egér használata, de többet hibáztam 
vele, mint a billentyűzettel. Lehetsé- 
ges, hogy csak nekem idegen az egér 
egy ilyen stílusú játéknál. És mint tud- 
juk, a megszokás nagy úr (a mai napig 





nem tudok FPS-t az ,invert mouse" 
bekapcsolása nélkül játszani). lehát 

a Frozen Bubble-hoz hasonlóan (igaz 
ott nincs is egér lehetőség) a billen- 
tyűzet használatát javaslom. 

Ez a két kis játék rendkívül jó, és félel- 
metes játékélményt nyújt. Gyakorlati- 
lag bárhol játszható. Az olyan a kisebb 
gépeken, ahol nincsen 3D-támogatás, 
vagy igen szerény eszközök bújnak 
meg bennük (ósdi gépek, régebbi lap- 
topok), remek választás. lermészete- 
sen rengeteg kisebb játék létezik még 
Linuxra (a jövőben többet is fogunk 
szemezgetni belőlük), de ez a kettő 
komoly sikert aratott a környeztem- 
ben, és bevallom (mint nagy FPS ra- 
jongó) bizony sok időre engem is 

a monitorhoz láncoltak. A kis játékok 
éppen úgy nyújthatnak felhőtlen szó- 
rakozást, mint nagy és drága társaik. 
Jó játékot kívánok mindenkinek! 


Dancsok Zoltán 
.] (stroggomail.tvnet.hu) 
.. XB j. Jelenleg technikai szerkesz- 
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